<type_traits>: Workaround for common_reference#2592
Conversation
(makes it harder to read at least for me...)
|
Thanks! I went ahead and pushed changes for the really minor things I noticed. Generally, I am allergic to permanently working around compiler deficiencies in type traits (as our ancient implementation of |
This comment was marked as resolved.
This comment was marked as resolved.
CaseyCarter
left a comment
CaseyCarter
left a comment
There was a problem hiding this comment.
I'm mildly concerned that we'll discover some corner where trait(s) that are intended to reflect language behavior disagree with what the compiler actually does. Defining is_convertible_v<int, int(*)(float)> to true, for example, doesn't magically make that conversion work. "Lying" about reflection doesn't really fix a bug so much as relocate it. I can find no such issues here with a bit of cursory investigation, however, so I think it's safe to merge this.
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Thanks for improving this type traits machinery to be more correct than the compiler! 😹 🚀 🎉 |
There is a long standing bug where MSVC incorrectly determines the result of `__is_constructible` when given cv-qualified types Furthermore, `common_reference` is broken similarly. This has been worked around in the MSVC standard library, so just port that fix from microsoft/STL#2592
There is a long standing bug where MSVC incorrectly determines the result of `__is_constructible` when given cv-qualified types Furthermore, `common_reference` is broken similarly. This has been worked around in the MSVC standard library, so just port that fix from microsoft/STL#2592
There is a long standing bug where MSVC incorrectly determines the result of `__is_constructible` when given cv-qualified types Furthermore, `common_reference` is broken similarly. This has been worked around in the MSVC standard library, so just port that fix from microsoft/STL#2592
There is a long standing bug where MSVC incorrectly determines the result of `__is_constructible` when given cv-qualified types Furthermore, `common_reference` is broken similarly. This has been worked around in the MSVC standard library, so just port that fix from microsoft/STL#2592
4 participants
Fixes #2581
Adds workaround for these cases:
When I is a cv-unqualified scalar type,
LRefiscvI&,RRefiscvI&&, MSVC generally erroneously computes_Cond_res<LRef, RRef>asI&, while the right result isI. Although sometimes pointer types get right results, and it seems thatI&&doesn't trigger the bug._Cond_res<volatile int&, const int&>is not fixed yet, butstd::common_reference_t<volatile int&, const int&>doesn't rely on its result.Additional workarounds:
_Cond_res<A&, A&&>incorrectly toA&whenAis an array type. The result should be decayed.volatile T(*)[N]andconst T(*)[N]to ill-defined result typeT volatile (const volatile*)[N]. Currently my workaround is incomplete. A complete workaround may need to hack the whole computation in [conv.qual]/3.