Use [[no_unique_address]] after Clang supports it on Windows

[StephanTLavavej]

VS 2019 16.9 will support [[no_unique_address]]. Clang lists this as supported in Clang 9. However, we suspect that it is not yet supported when Clang targets Windows, because MSVC didn't support it. So, #1363 is commenting out all of our [[no_unique_address]] usage.

• [X] Confirm whether Clang supports [[no_unique_address]] on Windows. (Clang does not.)
• [ ] If it does, proceed to the next step, otherwise we should file an LLVM bug requesting such support, then wait for it to be implemented and available in the version of Clang that ships with VS.
• [ ] Finally, we should begin using [[no_unique_address]] for C++20-only code.

[CaseyCarter]

VS 2019 16.9 will support [[no_unique_address]]. Clang lists this as supported in Clang 9. However, we suspect that it is not yet supported when Clang targets Windows, because MSVC didn't support it. So, #1363 is commenting out all of our [[no_unique_address]] usage.

• [ ] Confirm whether Clang supports [[no_unique_address]] on Windows.

When targeting MSABI Clang emits unknown attribute warnings for [[no_unique_address]]. This is peculiar given that the exact same binary with a different --target triple may understand the attribute just fine. I assume it was the simplest way to have the attribute do nothing until MSVC implements behavior for clang to mimic ensuring ABI compatibility.

• [ ] If it does, proceed to the next step, otherwise we should file an LLVM bug requesting such support, then wait for it to be implemented and available in the version of Clang that ships with VS.

I would guess that work on this will be blocked on access to an MSVC that implements [[no_unique_address]] for validation.

[AlexGuteniev]

I recall first reinventing and then reusing existent compressed pair for barrier callback. Just a reminder that at least C++20 uses of compressed pairs can be eliminated after this arrives.

[StephanTLavavej]

MSVC has implemented [[msvc::no_unique_address]] which is unconditionally available. However, it's probably too late to request Clang support and take advantage of it before the C++20 ABI lockdown of Ranges/Format/Chronat happens. We may be able to use this for C++23 before vNext though.

[AlexGuteniev]

@StephanTLavavej can plain [[no_unique_address]] be used in Clang, which is also unconditional?

struct S1 {};
struct S2 {};


#if defined(_MSC_VER)
#pragma warning(disable:4848)
#define _NO_UNIQUE_ADDRESS [[msvc::no_unique_address]]
#else
#define _NO_UNIQUE_ADDRESS [[no_unique_address]]
#endif

struct S
{
    _NO_UNIQUE_ADDRESS S1 s1;
    S2 s2;
};

int s()
{
    return sizeof(S);
}

https://godbolt.org/z/9PbKxM8ab

[AlexGuteniev]

@fsb4000 obseved that on Windows Clang does not support [[no_unique_address]] https://godbolt.org/z/x1bjbGz7a

[jyknight]

FYI, https://reviews.llvm.org/D110485 to support no_unique_address for Windows targets -- which, indeed, is blocked on concern of ABI incompatibility with MSVC.

I can't tell if there's some other outcome (besides Clang continuing to ignore it on windows for now) which would be desirable -- if so, might be nice to chime in!

[mstorsjo]

Based on observing various MSVC versions, while newer versions of MSVC (since 16.9) do support [[no_unique_address]], it seems to me like it has no effect, while [[msvc::no_unique_address]] does have effect - is that the correct conclusion? https://godbolt.org/z/xjec9vr7M shows what I'm observing.

[CaseyCarter]

Based on observing various MSVC versions, while newer versions of MSVC (since 16.9) do support [[no_unique_address]], it seems to me like it has no effect, while [[msvc::no_unique_address]] does have effect - is that the correct conclusion? https://godbolt.org/z/xjec9vr7M shows what I'm observing.

That is precisely the intended behavior. We were concerned about interjecting [[no_unique_address]] as an attribute that affects ABI while claiming ABI compatibility from VS 2015 to VS 2022, doubly so after we shipped a couple of point releases of VS 2019 that silently accepted [[no_unique_address]] and did nothing with it. [[msvc::no_unique_address]] is a compromise, in that we never shipped a compiler that wouldn't either diagnose or implement the ABI-affecting behavior.

[mstorsjo]

Based on observing various MSVC versions, while newer versions of MSVC (since 16.9) do support [[no_unique_address]], it seems to me like it has no effect, while [[msvc::no_unique_address]] does have effect - is that the correct conclusion? https://godbolt.org/z/xjec9vr7M shows what I'm observing.

That is precisely the intended behavior. We were concerned about interjecting [[no_unique_address]] as an attribute that affects ABI while claiming ABI compatibility from VS 2015 to VS 2022, doubly so after we shipped a couple of point releases of VS 2019 that silently accepted [[no_unique_address]] and did nothing with it. [[msvc::no_unique_address]] is a compromise, in that we never shipped a compiler that wouldn't either diagnose or implement the ABI-affecting behavior.

Thanks for the clarification!

[AlexGuteniev]

optional and expected currently don't benefit from compressed pair. They should use [[no_unique_address]] I guess.

[frederick-vs-ja]

If VS can be updated to use Clang 18 before C++23 ABI lockdown, it seems possible to use [[msvc::no_unique_address]] for in_value_result, out_value_result, and expected.