-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<type_traits>
: Workaround for common_reference
#2592
<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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Fixes #2581
Adds workaround for these cases:
When I is a cv-unqualified scalar type,
LRef
iscv
I&
,RRef
iscv
I&&
, 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&
whenA
is 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.