Re: [PATCH v2] Add infcall support for C++ constructor-style expressions

Hi,

On 6/26/26 5:06 PM, Kevin Buettner wrote:
> 
> Claude found this problem...
> > (gdb) file /tmp/test_c
> Reading symbols from /tmp/test_c...
> (gdb) start
> Temporary breakpoint 1 at 0x40044a: file /tmp/test_c.c, line 2.
> Starting program: /tmp/test_c
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Temporary breakpoint 1, main () at /tmp/test_c.c:2
> 2	int main() { struct S s = {42}; return s.x; }
> (gdb) print typeof(struct S)(42)
> /home/kevinb-claude/binutils-gdb-patch-review/gdb/eval.c:1885: internal-error: evaluate_funcall: Assertion `exp->language_defn->la_language == language_cplus' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> ----- Backtrace -----
> 0x51e699 gdb_internal_backtrace_1
> 	/home/kevinb-claude/binutils-gdb-patch-review/gdb/bt-utils.c:122
> 0x51e699 _Z22gdb_internal_backtracev
> 	/home/kevinb-claude/binutils-gdb-patch-review/gdb/bt-utils.c:173
> 0x9fb874 internal_vproblem
> 	/home/kevinb-claude/binutils-gdb-patch-review/gdb/utils.c:434
> 0x9fbd38 _Z15internal_verrorPKciS0_P13__va_list_tag
> 	/home/kevinb-claude/binutils-gdb-patch-review/gdb/utils.c:514
> 0xb6cea1 _Z18internal_error_locPKciS0_z
> 	/home/kevinb-claude/binutils-gdb-patch-review/gdbsupport/errors.cc:57
> 0x67e31c _ZN4expr14type_operation16evaluate_funcallEP4typeP10expression6nosideRKSt6vectorISt10unique_ptrINS_9operationESt14default_deleteIS8_EESaISB_EE
> ...
> 

Thanks for the report.

The root cause is that the C++-only gate lived only in the lexer, but
`typeof(T)` is a separate `type_exp` production. So in C, `typeof(struct
S)(42)` still matched the general `type_exp '(' arglist ')'` rules,
built a `funcall_operation`, and hit the `language_cplus` assert in
`type_operation::evaluate_funcall`.

The fix is to mirror the lexer gate in those parser actions: if the
language is not C++, throw an error:

(gdb) print typeof(struct S)(42)
Constructor-style casts are only valid in C++

I left the `type_exp`-based productions in place rather than splitting
out a dedicated ctor non-terminal; the language check closes the hole
Claude found without that larger grammar change. I'm happy to revisit
the shift/reduce side separately if consensus is reached. [This is the
direction a previous review steered me, and I am happy to revisit that
initial review recommendation.]

Thank you,
Keith