Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb@sourceware.org
Subject: Re: cp-name-parser.y
Date: Fri, 29 Feb 2008 21:49:00 -0000	[thread overview]
Message-ID: <20080229202918.GB7757@caradoc.them.org> (raw)
In-Reply-To: <47C861C5.4060907@qnx.com>

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


  reply	other threads:[~2008-02-29 20:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 18:39 cp-name-parser.y Aleksandar Ristovski
2008-02-29 19:09 ` cp-name-parser.y Daniel Jacobowitz
2008-02-29 19:32   ` cp-name-parser.y Aleksandar Ristovski
2008-02-29 19:49     ` cp-name-parser.y Daniel Jacobowitz
2008-02-29 20:15       ` cp-name-parser.y Aleksandar Ristovski
2008-02-29 21:49         ` Daniel Jacobowitz [this message]
2008-03-03 17:02           ` cp-name-parser.y Aleksandar Ristovski
2008-03-03 17:22             ` Daniel Jacobowitz
2008-03-03 18:33               ` cp-name-parser.y Aleksandar Ristovski
2008-03-03 20:05                 ` cp-name-parser.y Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229202918.GB7757@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox