Question about whether a code fragment is expected to parse.

Question about whether a code fragment is expected to parse.

[Iain Sandoe]

Hi

Given that GNU attributes are not part of the standard..

I wonder if the following is expected to work?

__attribute__((__deprecated__))
extern "C" __attribute__((__visibility__("default")))
void foo ()
{

}

t.C:3:8: error: expected unqualified-id before string constant
     3 | extern "C" __attribute__((__visibility__("default")))

===

Note that the C (and C++) front ends are happy to accept:

__attribute__((__deprecated__))
extern __attribute__((__visibility__("default")))
void foo ()
{

}

happy to file a PR/attempt a fix if we expect this to work
(clang accepts it, FWIW)

thanks
Iain

Re: Question about whether a code fragment is expected to parse.

[Nathan Sidwell]

On 10/25/20 7:52 AM, Iain Sandoe wrote:
> Hi
> 
> Given that GNU attributes are not part of the standard..
> 
> I wonder if the following is expected to work?
> 
> __attribute__((__deprecated__))
> extern "C" __attribute__((__visibility__("default")))
> void foo ()
> {
> 
> }
> 
> t.C:3:8: error: expected unqualified-id before string constant
>      3 | extern "C" __attribute__((__visibility__("default")))


I don't see why it should be will-formed.  'extern "C"' is a linkage 
specification, which precedes (or encloses) a declaration.  It is not 
storage-specified with an attached string constant.

nathan

-- 
Nathan Sidwell

Re: Question about whether a code fragment is expected to parse.

[Nathan Sidwell]

On 10/26/20 7:08 AM, Nathan Sidwell wrote:
> On 10/25/20 7:52 AM, Iain Sandoe wrote:
>> Hi
>>
>> Given that GNU attributes are not part of the standard..
>>
>> I wonder if the following is expected to work?
>>
>> __attribute__((__deprecated__))
>> extern "C" __attribute__((__visibility__("default")))
>> void foo ()
>> {
>>
>> }
>>
>> t.C:3:8: error: expected unqualified-id before string constant
>>      3 | extern "C" __attribute__((__visibility__("default")))
> 
> 
> I don't see why it should be will-formed.  'extern "C"' is a linkage

well-formed

> specification, which precedes (or encloses) a declaration.  It is not 
> storage-specified with an attached string constant.
> 
> nathan
> 


-- 
Nathan Sidwell

Re: Question about whether a code fragment is expected to parse.

[Iain Sandoe]

Nathan Sidwell <nathan@acm.org> wrote:

> On 10/26/20 7:08 AM, Nathan Sidwell wrote:
>> On 10/25/20 7:52 AM, Iain Sandoe wrote:

>>> Given that GNU attributes are not part of the standard..
>>>
>>> I wonder if the following is expected to work?
>>>
>>> __attribute__((__deprecated__))
>>> extern "C" __attribute__((__visibility__("default")))
>>> void foo ()
>>> {
>>>
>>> }
>>>
>>> t.C:3:8: error: expected unqualified-id before string constant
>>>      3 | extern "C" __attribute__((__visibility__("default")))
>> I don't see why it should be will-formed.  'extern "C"' is a linkage
>
> well-formed

OK. That’s fair - but these are GNU attributes, we could choose what
constitutes well-formed-ness (with sufficient justification and thought).

===

I checked with clang and:

__attrs
extern “C” [more attrs]
decl….

Applies _attr  and more attrs to decl… (it does also apply the linkage  
spec, of course)

__attrs
extern “C” {
  decl ..
  decl ..
}

silently [with -Wall Wextra] discards the __attrs (it does not apply them  
to the contained decls).

———

My difficulty is that clang’s acceptance of the [currently ill-formed, in  
GCC] prefix attributes on
a linkage spec has been baked into system headers, which will  break as  
soon as I apply
implemented missing functionality (it’s blocking that), so I need to  
formulate a way forward.

———

Options:

1/ we could make prefix attributes on a linkage spec well-formed IFF they  
applied to all decls covered by the linkage spec (so both cases above would  
get the prefix __attrs applied to all decls covered by the linkage spec).

  * If it is decided that this to remain ill-formed code, then we ought to issue a proper diagnostic (not just fall over on the extern decl spec).

  * fixing the clang bug, won’t fix the headers.

2/ I could make this work only for Objective-C (which is kinda partially  
done already), sorta yucky but in a bounded manner.

3/ I could make this work behind an -fclang-compatibility flag
   (there are a number of cases where similar problems exist, and I suspect that something along these lines will be needed to make Darwin GCC survive in the medium term).
 
4/ I could apply Yet More fix-includes (which is also yucky).

5/ other suggestions welcome.

===

* I made patches to make this work - those patches would also apply  
reasonably easily to
   (a) issuing a better diagnostic [1b]
   (b) making prefix attrs on linkage specs apply to ObjC++ only [2]
   and, I suppose, it would be equally easy to add a clang compat flag to hide them behind. [3]

* ISTM that -std=clang++XY isn’t going to work in the same way as gnu++XY  
does, since the behaviour for clang isn’t particularly gated on any  
standard version (AFAICT).
 
* In any event, I file a bug against clang because its actions are  
inconsistent,

* I’ve also asked the vendor to consider making future versions of the  
header well-formed (but that doesn’t solve what’s already in the wild).

thoughts?
Iain