From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12979 invoked by alias); 29 Feb 2008 20:29:42 -0000 Received: (qmail 12949 invoked by uid 22791); 29 Feb 2008 20:29:40 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Feb 2008 20:29:21 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 88C4F983A1 for ; Fri, 29 Feb 2008 20:29:19 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 66EE49831E for ; Fri, 29 Feb 2008 20:29:19 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JVBr4-00029L-IY for gdb@sourceware.org; Fri, 29 Feb 2008 15:29:18 -0500 Date: Fri, 29 Feb 2008 21:49:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: cp-name-parser.y Message-ID: <20080229202918.GB7757@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: <47C84D48.2020807@qnx.com> <20080229185513.GA2793@caradoc.them.org> <47C85859.2030403@qnx.com> <20080229193229.GA4226@caradoc.them.org> <47C861C5.4060907@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C861C5.4060907@qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00269.txt.bz2 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