Nasty parsing bug?

Abramo Bagnara abramo.bagnara at bugseng.com
Fri Aug 15 01:10:00 PDT 2014


Il 07/08/2014 15:42, Aaron Ballman ha scritto:
> On Thu, Aug 7, 2014 at 9:30 AM, Abramo Bagnara <abramo.bagnara at gmail.com> wrote:
>> On 07/08/2014 15:15, Aaron Ballman wrote:
>>> 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.
>>
>> Hmmm... but GCC compiles the source without any warning...
>>
>> Do you mean it is an undocumented feature of GCC or a GCC bug?
> 
> Undocumented feature, as far as I can tell. That would attach the
> attribute to the enum e type based on position, but it seems to
> appertain to the declaration instead.
> 
> But if GCC accepts this, we may want to consider implementing it as
> well if there's sufficient reason.

As we already behave in a GCC compatible way parsing

struct s
__attribute__((used)) x;
int __attribute__((used)) y;

I think that the proper fix is the attached one (i.e. we don't want to
detect as illegal something that later we will accept)

Ok to commit?

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com
-------------- next part --------------
Index: lib/Parse/ParseDeclCXX.cpp
===================================================================
--- lib/Parse/ParseDeclCXX.cpp	(revisione 215658)
+++ lib/Parse/ParseDeclCXX.cpp	(copia locale)
@@ -1068,6 +1068,8 @@
   case tok::kw___declspec:      // struct foo {...} __declspec(...)
   case tok::l_square:           // void f(struct f  [         3])
   case tok::ellipsis:           // void f(struct f  ...       [Ns])
+  // GCC compatibility
+  case tok::kw___attribute:     // struct foo __attribute__((used)) x;
     return true;
   case tok::colon:
     return CouldBeBitfield;     // enum E { ... }   :         2;


More information about the cfe-commits mailing list