[cfe-dev] decl/expr ambiguity

Argiris Kirtzidis akyrtzi at gmail.com
Mon Aug 25 02:16:01 PDT 2008


Doug Gregor wrote:
>
>> Are you talking about non-type template arguments ? I think in these cases
>> common parsing methods can be used by both a pre-parser and normal parser.
>>     
>
> Yes, that was the "fun" part I referred to. Template arguments can be
> types or expressions, so the parser needs to be able to disambiguate
> those (it resolves in favor of the type-id).
>   

If the template argument starts with "simple-type-specifier '('" or 
"typename-specifier '('" the pre-parser can fire off and look for an 
abstract declarator in order to disambiguate it. The pre-parser still 
doesn't need to deal with any of the expression syntax.

>   
>>> All that said, it might not matter so much whether we pre-parse now or
>>> not. As those trickier parsing bits for types go into the parser, they
>>> could probably be abstracted out to be useful for both the
>>> pre-parser(s?) and the parser, to eliminate unnecessary code/coding
>>> duplication.
>>>
>>>       
>> Certainly! Resolving scope qualifiers and instantiating classes can be
>> shared.
>>     
>
> How far does "instantiating classes" extend? Will we be sharing the
> parsing of typename-specifiers and template-ids, for example?
>   

Yes, disambiguation only cares for types (ok and 
nested-name-specifiers), so methods like ParseTypeNameSpecifier and 
ParseClassTemplateId can be shared.
They would return a TypeTy* like ParseTypeName currently does (which 
they would cache to avoid doing instantiations multiple times).


-Argiris




More information about the cfe-dev mailing list