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
On Fri, 15 Jul 2011 22:58:28 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 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.
You are close but I do not think it matters.
One can have purely C program which has dynamically (even indirectly) linked
some library in C++ and one should be able to access C++ expressions in that
library. One cannot with the main program is in Fortran or other languages
but C vs. C++ are both mixed in the real world and also their parsing does not
conflict too much.
> 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.
I agree, c-exp.y already tries to resolve everything to OP_TYPE and
OP_VAR_VALUE. I admit I tried to remove but the code still depends on it.
Also non-C languages use OP_SCOPE. I find that cleanup as a different one
/ additional one.
Thanks,
Jan