[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