Missing [[no_unique_address]] support on Windows

[ClawmanCat]

Bugzilla Link	50014
Version	trunk
OS	Windows NT
Attachments	test.cpp: the source file that triggers the warning. log.txt: console output from compiling test.cpp.
CC	@AaronBallman,@CaseyCarter,@Ivan171,@zygoloid

Extended Description

https://clang.llvm.org/cxx_status.html#cxx20 lists the [[no_unique_address]] attribute as supported since Clang 9. However, the attribute does not seem to currently be supported on Windows platforms.

Compiling the following source code on Windows with Clang 12.0.0 with -std=c++20:

struct X {};

struct Y1 {
	[[no_unique_address]] X x;
	long long a;
};

struct Y2 {
	X x;
	long long a;
};

int main() {}

gives the following warning:

test.cpp:4:4: warning: unknown attribute 'no_unique_address' ignored [-Wunknown-attributes]
        [[no_unique_address]] X x;
          ^~~~~~~~~~~~~~~~~
1 warning generated.

The size of objects from Y1 are also the same size as those from Y2, indicating that an unique address is indeed still generated:

std::cout << sizeof(Y1) << ", " << sizeof(Y2);

prints "16, 16" compared to "8, 16" on Linux: https://godbolt.org/z/nfaf3KeP3

[Ivan171]

*** Bug llvm/llvm-bugzilla-archive#51051 has been marked as a duplicate of this bug. ***

[AaronBallman]

This is not a bug. Microsoft has not defined the ABI for this attribute on their platform, so Clang needs to wait for Microsoft to define that before we can support [[no_unique_address]] there (otherwise we run into potential ABI incompatibilities).

However, I'm leaving this request open because presumably Microsoft will define the ABI on their platform for this feature, and then Clang can follow suit.

[ClawmanCat]

This is not a bug. Microsoft has not defined the ABI for this attribute on
their platform, so Clang needs to wait for Microsoft to define that before
we can support [[no_unique_address]] there (otherwise we run into potential
ABI incompatibilities).

However, I'm leaving this request open because presumably Microsoft will
define the ABI on their platform for this feature, and then Clang can follow
suit.

Microsoft already added support for this as of VS 2019 16.9.
(https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-160)

[AaronBallman]

This is not a bug. Microsoft has not defined the ABI for this attribute on
their platform, so Clang needs to wait for Microsoft to define that before
we can support [[no_unique_address]] there (otherwise we run into potential
ABI incompatibilities).

However, I'm leaving this request open because presumably Microsoft will
define the ABI on their platform for this feature, and then Clang can follow
suit.

Microsoft already added support for this as of VS 2019 16.9.
(https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-
conformance?view=msvc-160)

Alas, but I don't believe the documentation based on how their compiler behaves in practice (which is not something Clang will be emulating because it looks to be a buggy implementation). See https://godbolt.org/z/j1PzbK68P, but basically, __has_cpp_attribute returns false for both no_unique_address and msvc::no_unique_address, yet the latter actually does the correct thing that the former is standardized to do while the former is silently ignored.

[CaseyCarter]

It is not intended that MSVC predefines __has_cpp_attribute(msvc::no_unique_address) to 0. (Copy-pasta strikes again!) I'll get it changed to 201803L. It is intentional that MSVC predefines __has_cpp_attribute(no_unique_address) to 0, however - we don't consider the no-op implementation to be worthy of claiming support for the attribute.

As an STL developer, I would greatly appreciate if clang-cl were to implement [[msvc::no_unique_address]]. I'm willing to bribe people with adult beverages =)

[Ivan171]

mentioned in issue #50395

[AaronBallman]

It is not intended that MSVC predefines
__has_cpp_attribute(msvc::no_unique_address) to 0. (Copy-pasta strikes again!) I'll get it changed to 201803L.

Thanks!

It is intentional that MSVC predefines __has_cpp_attribute(no_unique_address) to 0, however - we don't consider the no-op implementation to be worthy of claiming support for the attribute.

Personally, I think it's unfortunate that Microsoft is not implementing the standard attribute but are instead creating problems by introducing a vendor-specific attribute that behaves the same as the standard attribute.

As an STL developer, I would greatly appreciate if clang-cl were to implement [[msvc::no_unique_address]]. I'm willing to bribe people with adult beverages =)

As someone who writes portable code and hates jumping through ridiculous hoops to do so, I would greatly appreciate if cl were to implement [[no_unique_address]] (I, too, can bribe people with adult beverages!).

That said, I have no problem with Clang implementing [[msvc::no_unique_address]] so long as we match Microsoft's ABI for it. Is there any documentation available on the ABI for this?

[zmodem]

I'm not sure what the best way forward is for us here. Since MSVC treats [[no_unique_address]] as a no-op, we can't implement it in a way that's both compatible and standards-conforming. But just waiting isn't great either.

Is [[no_unique_address]] used in any MS system headers yet? How bad would it be if we ignore MSVC here and just use clang's current implementation?

Also, like it or not, if there is a bunch of code using [[msvc::no_unique_address]], we'll probably have to implement it. I see it's mentioned in libc++ already (https://github.com/llvm/llvm-project/blob/05337a7/libcxx/include/__config#L1404). I wonder if just aliasing it to the current attribute would work..

cc'ing @mstorsjo @nico and @rnk

[AaronBallman]

But just waiting isn't great either.

Agreed that it's not great, but rushing is also not great given the ABI concerns.

How bad would it be if we ignore MSVC here and just use clang's current implementation?

I'm strongly opposed because of ABI. Using fields with [[no_unique_address]] will have potentially different offsets depending on whether compiling with clang-cl or cl.

Also, like it or not, if there is a bunch of code using [[msvc::no_unique_address]], we'll probably have to implement it.

I'm absolutely happy to see an implementation for it once we know we can match the Microsoft ABI for it. Without that, I have the same ABI concerns as above.

[nico]

It sounds like supporting [[msvc::no_unique_address]] is uncontroversial, so we should do that.

For [[no_unique_address]], how about we make up a mangling (that's unlikely to colilde with cl), use clang's existing codepath for it, and emit some -Wmicrosoft- warning that says "ABI-incompatible with cl.exe" when it's used in ms mode?

[AaronBallman]

It sounds like supporting [[msvc::no_unique_address]] is uncontroversial, so we should do that.

+1, hopefully someone from Microsoft can help with the ABI questions so we don't have to reverse engineer it.

For [[no_unique_address]], how about we make up a mangling (that's unlikely to colilde with cl), use clang's existing codepath for it, and emit some -Wmicrosoft- warning that says "ABI-incompatible with cl.exe" when it's used in ms mode?

The warning helps but it doesn't actually address the ABI issues (users are still going to have a hard ABI break and this decreases our compatibility with MSVC). I think when the user passes -fms-compatibility, we should be compatible with MSVC.