Nathan Sidwell <nat...@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
