Underlying type of unscoped and unfixed member enumerations of class templates

[thebrandre]

If compatibility with MSVC is enabled, Clang correctly uses int as the underlying type of an unscoped enumeration even if the assigned integer causes an overflow - at least at namespace scope. This is correct in the sense of compatibility, which is officially documented by Microsoft here.

However, if the same declaration appears inside a class template, -fms-compatibility is not honored.

template <typename T>
struct S {
    enum E { X, Y = 0xFFFFFFFF };
};

enum E { X, Y = 0xFFFFFFFF };

constexpr bool check(int) { return true; }
constexpr bool check(unsigned int) { return false; }

static_assert(check(E::X), ""); // succeeds
static_assert(check(S<char>::E::X), ""); // fails

See here on Compiler Explorer: https://godbolt.org/z/Ge8qehE5P

I am aware that there are a lot of open issues on the underlying type of enumerations when using -fms-compatibility (#120759 #122032 #1883 to name a few) but this one should be orthogonal.

[thebrandre]

On the bright side, there is quite an easy fix for it. In fact, I only stumbled upon it because I wanted to refactor the code. I guess, this case was simply overlooked in Clang's implementation.

While this is technically an ABI-breaking change due to name mangling (if you extract the underlying type and make it part of the ABI, see https://godbolt.org/z/WEbc6Eb1T) when linking clang-cl binaries to clang-cl binaries, it should hardly ever occur in practice.
So my question is: is it acceptable to silently fix this without introducing yet another compiler switch? 😊

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: André Brand (thebrandre)

If compatibility with MSVC is enabled, Clang correctly uses `int` as the underlying type of an unscoped enumeration even if the assigned integer causes an overflow - at least at namespace scope. This is correct in the sense of compatibility, which is officially documented by Microsoft [here](https://learn.microsoft.com/en-us/cpp/build/reference/zc-enumtypes?view=msvc-170).

However, if the same declaration appears inside a class template, -fms-compatibility is not honored.

template <typename T>
struct S {
    enum E { X, Y = 0xFFFFFFFF };
};

enum E { X, Y = 0xFFFFFFFF };

constexpr bool check(int) { return true; }
constexpr bool check(unsigned int) { return false; }

static_assert(check(E::X), ""); // succeeds
static_assert(check(S<char>::E::X), ""); // fails

See here on Compiler Explorer: https://godbolt.org/z/Ge8qehE5P

I am aware that there are a lot of open issues on the underlying type of enumerations when using -fms-compatibility (#120759 #122032 #1883 to name a few) but this one should be orthogonal.