[cfe-dev] decl/expr ambiguity
doug.gregor at gmail.com
Mon Aug 25 07:10:17 PDT 2008
On Mon, Aug 25, 2008 at 5:16 AM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Doug Gregor wrote:
>>> Are you talking about non-type template arguments ? I think in these
>>> common parsing methods can be used by both a pre-parser and normal
>> 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.
Sure it does. If the template argument isn't a type-id, it's an
expression. The pre-parser doesn't need to parse these expressions,
but it needs to be able to reliably skip over them. That means at
least some parsing to tell when, e.g., '>' is an operator vs. a '>'
that closes a template-argument-list ('>>' is similar, for
error-recovery and C++0x). So we can simplify parsing of expressions,
but it still needs to be there in some form.
>>>> 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
>>> Certainly! Resolving scope qualifiers and instantiating classes can be
>> 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).
If we're sharing ParseTypeNameSpecifier and ParseClassTemplateId (and,
therefore, most of the tricky logic for parsing types), then I'm not
as worried that the pre-parser will require a significant amount of
More information about the cfe-dev