[cfe-dev] [PATCH] C++ decl/expr ambiguity resolution
clattner at apple.com
Sat Aug 23 17:37:07 PDT 2008
On Aug 23, 2008, at 3:01 AM, Argiris Kirtzidis wrote:
>> Hmm... I see the following: "Note: To disambiguate, the whole
>> statement might have to be examined to determine if it is an
>> expression-statement or a declaration." I think this is pretty
>> if there were some allowable shortcuts, they would be documented in
>> the standard.
> Yes but the "might have..." is pretty... ambiguous :)
> One might say,
> "by examining these parts of the statement I can conclude whether
> it's a declaration or expression"
> another one might say
> "these parts are not enough, I'll continue to examine the rest of
> the statement".
> The standard says "statement disambiguated as a declaration may be
> an ill-formed declaration", so the first one can say "with these
> parts of the statement I concluded it's a declaration, if the next
> parts do not compile as a declaration then it's an ill-formed
> If the standard said "the whole statement *should* be examined to
> determine.." it would be more clear. But this is very subtle and I
> may be wrong.
I agree with Eli. The standard is very clear here, and it sounds like
these are bugs in GCC. Specifically, if a whole statement can be
parsed as a declaration, it should be. If the whole statement can't,
and it is legal as an expression, then it must be parsed as a
statement. Rejecting a legal expression because it doesn't fit the
declaration syntax would be a bug.
> The issue is mostly how to deal with comma separated declarators/
> int(x), ++x;
> if we examine "++x" we will conclude that this is an expression. If
> we only examine "int(x)" we will regard this as declaration (note
> that the C++ standard does not have such an example).
> GCC examines only the first declarator, while MSVC examines all of
> Given that comma separated declarators are *much* more common than
> comma separated expressions, and that a function-style cast followed
> by a comma is mostly useless, I chose to go along with GCC and only
> examine the first declarator.
I agree that this isn't a common case, but it would be very preferable
for clang to get it right. :)
Another related but purely orthogonal issue is the efficiency
concern. It is preferable to avoid backtracking in obvious cases
where we know that something is a statement. For example, it is
impossible for a declaration to start with the 'do' keyword, so if we
see that, we can avoid the cost of starting/reverting backtracking.
More information about the cfe-dev