This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cp-name-parser.y


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
>> table.
> 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.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]