From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5385 invoked by alias); 11 Feb 2010 21:00:22 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 5369 invoked by uid 22791); 11 Feb 2010 21:00:21 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SARE_LWSHORTT,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Sami Wagiaalla Cc: archer@sourceware.org Subject: Re: [rfc] patch for pr8880 References: <4B703D65.302@redhat.com> <4B71B645.2050806@redhat.com> Reply-To: Tom Tromey Date: Thu, 11 Feb 2010 21:00:00 -0000 In-Reply-To: (Tom Tromey's message of "Tue, 09 Feb 2010 16:35:20 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2010-q1/txt/msg00078.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> c-exp.y does sometimes differentiate the cases; it will emit an Tom> OP_SCOPE in the qualified case. I think we do mishandle either Tom> "::name" or "::name::name" here, in the sense that these aren't Tom> distinguished from a name without a leading "::". Sami mentioned that this was handled on expr-cumulative. I looked, and it does seem to be partially handled, but I think there are still bugs. Also, parts of the implementation are bad -- checking for "::" in lookup_symbol_in_language is a no-no. I may end up redoing this; if you're actively working in this area, let me know, and I will back off. Tom> I've been sort of nosing around PR 9496 and PR 8693, but I haven't Tom> really committed yet. There is a big comment before the qualified_type Tom> production that explains the problem. Tom> I was thinking that maybe we could try to do more in the lexer and Tom> differentiate between the kinds of qualified names there. This is Tom> probably simplest, though I suspect it may cause us some pain later on. Tom> The other idea I had was to require bison and somehow use the GLR parser Tom> feature to let us differentiate the cases. It is a little hard to see Tom> exactly how this would work, but I haven't looked at it too deeply yet. I think in the short term I am going to try hacking the lexer here. This should let us solve a number of frequently-reported bugs without undue pain or regressions. In the longer term, though, we will have to push all this into the parser, the comment before the use of find_template_name_end explains why. Tom