[PATCH] D122874: [clang] Add GNU spelling for no_unqiue_address attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D122874#3430672 <https://reviews.llvm.org/D122874#3430672>, @philnik wrote:

>> And if `[[msvc::no_unique_address]]` and `[[no_unique_address]]` (when eventually implemented) in MSVC have a different ABI impact, will we will leave `__attribute__((no_unique_address))` alone so it won't break ABI?
>
> I think that would depend on how Microsoft breaks the ABI. If there would be different mangling it would probably be best to also break the ABI of `__attribute__((no_unique_address))`, and I think that would be the most likely scenario.

Hmmm, I'd be more comfortable if this wasn't an ABI break for people using the `__attribute__(())` spelling. If we wanted to surprise users with ABI breaks, we'd just implement `[[no_unique_address]]` on Windows and break users when Microsoft eventually supports the attribute, which is an approach I'm rather strongly opposed to. In this case, it's a bit different because it's a GNU-style spelling and Microsoft doesn't support that spelling at all, so my thinking was that we could define the ABI for it and make it stable because it's our extension. But I can see why you'd want something different in libc++.

So here's a potential path forward (thinking out loud, so this is not fully thought through and may be a bad idea): pick whatever ABI makes sense for `__attribute__((no_unique_address))`, document that the ABI is currently unstable for this spelling, and if we need to break the ABI then libc++ can use ABI tags on the structure to keep things compatible? And once we get the ABI-stable version, we can update the docs accordingly.

>> I believe we care about ABI stability, even on Windows. At the very least, I've never heard that the community does not care about ABI stability on Windows.
>
> Sorry, with 'we' I meant libc++. Because libc++ is never the primary c++ standard library on Windows most programs that use it ship their own version, so ABI stability isn't really an issue there. I think there is also a mingw environment with libc++, but IIRC there ABI stability was also more of a nice-to-have than an absolute need-to-have.

Ah, okay, that makes more sense to me. However, this attribute isn't exposed just for libc++ folks; anyone will be able to use it for whatever they want, so my ABI concerns are for the wider audience.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122874/new/

https://reviews.llvm.org/D122874