Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units

[Daniel Jacobowitz <drow@false.org>]

On Mon, Feb 20, 2006 at 10:46:08AM -0500, Fred Fish wrote:
> OK, here is a patch. I'm not entirely happy with it but I'm not familiar
> enough with parser generator input and output to see any obviously 
> better way.
> 
> The basic problem is that it's easy to handle 'file'::variable.  The
> existing code for this is:
> 
>   block :  block COLONCOLON name
>                   { struct symbol *tem
>                       = lookup_symbol (copy_name ($3), $1,
>                                         VAR_DOMAIN, (int *) NULL,
>                                         (struct symtab **) NULL);
> 
> What happens is that "name" is handled by a lookup_symbol call with
> no context block specified, and then the above calls lookup_symbol
> again with the context specified by $1 (block).
> 
> But for types, the parser generator input is:
> 
>   type    :       ptype
>           |       block COLONCOLON ptype
>                         { $$ = $3; }
> 
> Setting expression_context_block for the duration of parsing the
> input expression was the only obvious way I saw to work around
> not being able to call lookup_symbol again, with the right block.
> 
> I tried setting expression_context_block on the lexer code when it
> returned BLOCKNAME or FILENAME and that broke some other stuff.
> 
> Any suggestions on better ways to handle this would be great.

Yuck.  In general futzing with global variables in a parser is bad
news.  And here's another good hint that this isn't happening in the
right place:

  type  :       ptype         
+       |       block COLONCOLON ptype                              
+                       { $$ = $3; }                      

but ptype : typebase, and typebase : INT_KEYWORD.  So this will allow
"ptype var.c:int".  I don't think that's a great idea (especially since
we won't use the debug info to look up "int" in that case anyway so we
still won't detect a mismatch).

The problem you're having is that the lexer looks up symbols without
knowing their context.  I think you're going to have some fragile
failure modes with things that are types in one file and not in
another, which it would be nice to support if we could.  The fact
that we try to differentiate between these two in the lexer is
a bit problematic.

One easy way to improve here would be to just look up the symbol
again.  But that still relies on the lexer having decided this
was a typename.

I'm not sure what to suggest.  Really this parser needs some more
thorough love and care.

-- 
Daniel Jacobowitz
CodeSourcery