This is the mail archive of the
mailing list for the GDB project.
On Fri, Feb 29, 2008 at 02:49:25PM -0500, Aleksandar Ristovski wrote:
> Daniel Jacobowitz wrote:
>> On Fri, Feb 29, 2008 at 02:09:13PM -0500, Aleksandar Ristovski wrote:
>>> I am looking at that since right now something like this:
>>> -var-create - * "(anonymous namespace)::foobar"
>>> will not work since c_parse doesn't know anything about '(anonymous
>>> namespace)'. I guess it wouldn't be too hard to hack around this
>>> particular case, but a proper solution would be preferable.
>> I wonder what the right thing to do on a statement like that is. The
>> problem with anonymous namespaces is that we call them all "(anonymous
>> namespace)", but they're many different namespaces, one for each file
>> with anonymous namespaces. In that file, you would access the type
>> as just "foobar". Maybe we should give each anonymous namespace
>> a different name.
> I am not sure, but unique name should already be available in the form of
> mangled name (to me, at a first glance, creating unique names doesn't
> sound like a good idea).
Yes, we could take the unique string from the mangled name and call it
(anonymous namespace _MESS_OF_GARBAGE)::foobar, and then recognize
that syntax when we parse expressions.
> However, in the case I am talking about, it is known which anonymous
> namespace is relevant since we have the frame, so really the only thing
> that is missing is to recognize that '(anonymous namespace)' could,
> effectively, be removed from the type name and then using the 'bare' var
> name crawl up the blocks to find the matching visible var in the given
> context. But I am not 100% sure the solution is generic.
I don't know how the existing anonymous namespace code works. It was
David Carlton's work and I wasn't following it at the time. We need
them internally, to get bare lookup right, but maybe we should not
display them to the user - just call the type "foobar".
If we do that, though, what if there are multiple types named foobar?
Completely legal C++. Well, no worse than the problem we have in C
anyway - so maybe that's the change we should make.
>> Anyway, cp-name-parser.y isn't a replacement for c-exp.y. It's a name
>> parser; it accepts both names and types in cases where we don't know
>> which are which, and it does not support any expressions except when
>> they can appear inside a template argument. Once you've identified
>> something as a symbol name then you might hand it off to this parser
>> to find the canonical form of the name, before searching the symbol
> ok. So we could, perhaps, use it if c_parse fails and the language is c++?
No. The two parsers are for different things. We could recognize
that things with (anonymous namespace) in them are the names of C++
symbols in c-exp.y.