Nasty parsing bug?
Aaron Ballman
aaron at aaronballman.com
Thu Aug 7 06:15:06 PDT 2014
On Thu, Aug 7, 2014 at 5:39 AM, Abramo Bagnara
<abramo.bagnara at bugseng.com> wrote:
> In the following source
>
> enum e { a };
> enum e __attribute__((unused)) x;
> enum e
> __attribute__((unused)) y;
>
> the declaration of x is parsed without errors, but the declaration of y
> gives a parse error i.e. the presence of the newline makes a difference (!)
>
> Indeed I cannot imagine a reason why the parsing should be influenced by
> token position.
>
> Opinions anyone?
Both are illegal parses -- a GNU-style attribute cannot appear in that
location. The reason the behavior differs is in ParseEnumSpecifier,
around line 3667; we notice that the declaration isn't valid, and
guess that it's because it's missing a semicolon at the end of the
forward reference to enum e. This happens because __attribute__ is at
the start of the line for your third case. For your second case, we do
not perform the error recovery because __attribute__ is not at the
start of the line.
We could be a bit more friendly by attempting to parse the attributes,
and diagnosing them as being prohibited in that location.
HTH!
~Aaron
More information about the cfe-commits
mailing list