[cfe-dev] decl/expr ambiguity
akyrtzi at gmail.com
Mon Aug 25 09:38:54 PDT 2008
Doug Gregor wrote:
> On Mon, Aug 25, 2008 at 5:16 AM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
>> 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.
I wasn't clear enough; I was thinking that parsing template arguments
and class instantiations in general would be the job of a shared
ParseClassTemplateId, not the responsibility of the pre-parser. So the
pre-parser won't actually skip anything, they will be parsed and
instantiated properly by ParseClassTemplateId.
ParseClassTemplateId, in turn, may need to fire-off a pre-parser
instance just to determine whether a template argument is a type-id or
>> 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
Yeah, if the pre-parser was required to properly parse expressions it
would definitely be a nightmare ! :-)
More information about the cfe-dev