c-exp.y

[David Carlton <carlton at math dot stanford dot edu>]

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