From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30827 invoked by alias); 17 Dec 2002 20:59: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 30798 invoked from network); 17 Dec 2002 20:59:31 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 17 Dec 2002 20:59:31 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gBHKwX211425; Tue, 17 Dec 2002 12:58:33 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Subject: c-exp.y From: David Carlton Date: Tue, 17 Dec 2002 12:59:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00257.txt.bz2 Is anybody out there an expert on c-exp.y? I'm playing around with it right now, I've run into a bit of a mess, and I could use some hand-holding. (It doesn't help that it's been almost a decade since I last dealt with YACC.) 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. Currently, if I understand it correctly (which may well not be the case), that support is handled within c-exp.y in two different ways: 1) The #if 1 section of yylex handles the case of nested types. So if the lexer runs into C::D, it checks to see if C::D looks like a nested type, and if so it swallows the entire string C::D. (Its way of calculating the nested type in question isn't too great, but never mind that.) Otherwise, it just swallows the string C, and the next call to yylex will swallow the :: (returning a COLONCOLON token). 2) The 'qualified_name' symbol handles the case C::x where C is a class and x is a (non-type) member of that class. This division of responsibilities seems like a mess. (And I'm leaving out the case of ::x or ::C::x, which I still haven't tried to figure out.) 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. Question 1: Is what I say above correct? Question 2: What should I do about it? Working on the assumption that we need to distinguish between types and non-types, I added a 'qualified_type' symbol to parallel 'qualified_name'. This gave me one more shift/reduce conflict and 8 more reduce/reduce conflicts; I wasn't sure whether or not that was a big deal (like I said, it's been a while since I last used YACC), so I pressed on with it. After running it on some test data, I found that it worked in most situations, but it broke ptype on qualified types. What I think is going on is that we have the rule start : exp1 | type_exp ; and, if you have a qualified expression, then there are two possible paths in the grammar to reach 'start' (with the last step being either via 'qualified_name' or 'qualified_type'); Bison chose the former, which shuts off the possibility of qualified expressions ever being interpreted as types. (So, given C::D::x, C::D is a type via qualified_type, but C::D::x is never a type.) This presumably is reflected in the extra conflicts that I got. Question 3: Is what I've said since my last questions correct? Question 4: Again, what should I do about it? For now, it seems to me that probably c-exp.y has some conceptual problems that are too big for me to deal with; so I'm leaning towards going back to the original solution of shoving nested types back into the lexer. I still feel that's the wrong place for that, but I should be able to get it to work. And I'm still nervous about the initial double-colon case: I suspect that the lexer can't handle that, unless it handles all situations involving double-colons. Sigh. David Carlton carlton@math.stanford.edu