[PATCH] D110485: Support [[no_unique_address]] for all targets.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D110485#3033889 <https://reviews.llvm.org/D110485#3033889>, @expnkx wrote:

> https://github.com/microsoft/STL/issues/1364
>
> As Microsoft said, the reason why things like msvc::no_unique_address exist are because clang does not support it. In fact, it has become a vicious cycle. msvc waits clang, clang waits msvc.
>
> It is a vicious cycle. I would argue it is LLVM's fault, not Microsoft's fault.

I don't know why anyone would assume that Clang would be more responsible for defining the behavior of a feature on Windows than Microsoft. Microsoft is the owner for their ABI, not Clang. When this feature was introduced into Clang, we explicitly did not allow it on Windows until Microsoft defined what the ABI is for the feature. Now that Microsoft has decided to define `[[msvc::no_unique_address]]` with a particular ABI, it would be reasonable for us to support *that* spelling. However, it would be unacceptable for us to define the behavior for `[[no_unique_address]]` in a way that's different from the ABI Microsoft picks for it.

Note: it *might* be reasonable for us to define `[[no_unique_address]]` as being ignored on Windows targets as that seems to be the direction Microsoft wants to go. However, I personally view the Microsoft behavior here to be user-hostile and so I'd like to see whether they're planning to change directions before we decide to follow along. However, if Microsoft's position is that they're not going to implement the semantic effects for `[[no_unique_address]]`, Clang will follow suit on the Windows target.

> Sure you can add another attribute, i tried that, but adding another attribute for doing exactly the same thing through entire code base is just annoying and headache.
>
> If clang does not support [[no_unique_address]], Microsoft is not going to support it either. Microsoft's own words.

And Microsoft's own choice.

> [[no_unique_address]] is ISO C++ standard. Why not support it? I am sorry the entire LLVM did a crappy job on support C++20 standard in general.

In keeping with our code of conduct (https://llvm.org/docs/CodeOfConduct.html), please keep your comments respectful.


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

https://reviews.llvm.org/D110485