This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Be in language c more c++ compatible
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 15 Jul 2011 14:58:28 -0600
- Subject: Re: [rfc] Be in language c more c++ compatible
- References: <20110715191920.GA29975@host1.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -
Jan> FSF GDB HEAD
Jan> (gdb) show language
Jan> The current source language is "auto; currently c".
I am curious why this happens.
It seems like it should say "currently c++" -- I didn't check the code
but my mental model would be that if there is no frame, then the default
symtab should either be 'main' or, if no main, say the first CU in the
symbol file; and the default symtab's language should be used for auto.
Jan> The first (c-exp.y) part parses those parts of `language c++' which cannot
Jan> (I believe - RFC) lead to misinterpretation of any valid C code even in
Jan> `language c'.
I think so, though one would have to check eval.c and friends as well to
be certain.
Jan> The second (valops.c) part is there because with `language c++'
Jan> parsing "C::t" is straight OP_TYPE handled correctly in
Jan> evaluate_subexp_standard. But with `language c' it gets parsed as
Jan> OP_SCOPE and I find there a bug, copied the code there.
I don't even know why we have OP_SCOPE.
Tom