failed tests/Dev09_172666_tr1_tuple_odr

Same thing. I ran into the issue yesterday: #2739 (comment)

template <class>
_INLINE_VAR constexpr bool _Is_EcharT = false;
template <>
_INLINE_VAR constexpr bool _Is_EcharT<char> = true;

in two different cpp files gives fatal error LNK1169: one or more multiply defined symbols found with clang-cl and C++14.
because _INLINE_VAR is nothing in C++14.

I think you can use _Is_any_of_v too

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

This breaks the compiler backend with:

   643>D:\msvc\binaries\x86chk\inc\unordered_map(50,99): error C2280: 'std::_Uhash_compare<_Kty,_Hasher,_Keyeq>::_Uhash_compare(const std::_Uhash_compare<_Kty,_Hasher,_Keyeq> &)': attempting to reference a deleted function [D:\msvc\src\vctools\Compiler\Utc\build\arm64\utc-arm64.nativeproj]
                 with
                 [
                     _Kty=std::basic_string<char,std::char_traits<char>,UtcPoolAllocator<T_ALLOC,char>>,
                     _Hasher=std::hash<std::basic_string<char,std::char_traits<char>,UtcPoolAllocator<T_ALLOC,char>>>,
                     _Keyeq=std::equal_to<void>
                 ]
             explicit _Umap_traits(const _Tr& _Traits) noexcept(is_nothrow_copy_constructible_v<_Tr>) : _Tr(_Traits) {}
                                                                                                           ^

This isn't necessarily blocking (we could change the backend to use a custom hash), but it indicates that this change will be highly breaking.

I think we should speculatively implement LWG-3705 "Hashability shouldn't depend on basic_string's allocator" here, now that @CaseyCarter's newly filed issue has a number. I'll validate and push changes to avoid having to drop this from the mirror PR.

Thanks for improving conformance here and fixing these libcxx skips! 🎉 😻 ✅