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
next prev parent 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