From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25554 invoked by alias); 17 Dec 2002 21:43:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25496 invoked from network); 17 Dec 2002 21:43:37 -0000 Received: from unknown (HELO tully.CS.Berkeley.EDU) (128.32.153.227) by 209.249.29.67 with SMTP; 17 Dec 2002 21:43:37 -0000 Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.9.1a/8.9.1) with ESMTP id NAA14438; Tue, 17 Dec 2002 13:43:22 -0800 (PST) Message-Id: <200212172143.NAA14438@tully.CS.Berkeley.EDU> To: gdb cc: carlton@math.stanford.edu Subject: Re: c-exp.y MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14433.1040161402.1@tully.CS.Berkeley.EDU> Date: Tue, 17 Dec 2002 13:43:00 -0000 From: Paul Hilfinger X-SW-Source: 2002-12/txt/msg00262.txt.bz2 > Basically, I want to revamp the way that GDB handles qualified names > in C++: these are names like C::x or C::D::y or whatever, where C > and/or D might be classes or namespaces. A noble goal, but rather difficult, to say the least. > Unfortunately, some sort of distinction between types and > non-types seems to be hard-wired into the parser at a deep level: it > seems to be the parser's job to actually evaluate expressions > corresponding to types, whereas other expressions get evaluated by > somebody else. Yes. This is a well-known issue with C++ parsing. Consider (T) *x We must know whether T is a type to know whether this is a cast. Of course, the most infamous characteristic of C++ syntax is even worse. Even if you know that T is a type name, T(x); may be parsed either as a declaration of x or as an invocation of the constructor for T on argument x (yielding a value of type T that is voided). The rule is that this is a declaration. > Question 2: What should I do about it? I hesitate to bring this up, but the newest versions of Bison support GLR parsing, which can handle the infamous case. In principle, one could use GLR parsing to push off the distinction between types and non-types to a later stage of the compiler, but this is probably not a wise way to use it. Still, I suspect that GLR parsing could clean up at least some things in the C++ grammar. Unfortunately, the feature is new and experimental, and will need shaking down. It is also not in yacc or (at least for now) byacc, which may or may not be a problem. On the other hand, I know for a fact that, starting next month, GLR's contributer would be willing to work on getting the kinks out (;->). Paul Hilfinger