Re: [rfc] Be in language c more c++ compatible

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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