Skip to content
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

Merged

Conversation

frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Feb 25, 2022

Fixes #2581

Adds workaround for these cases:
When I is a cv-unqualified scalar type, LRef is cvI&, RRef is cvI&&, MSVC generally erroneously computes _Cond_res<LRef, RRef> as I&, while the right result is I. Although sometimes pointer types get right results, and it seems that I&& doesn't trigger the bug.

_Cond_res<volatile int&, const int&> is not fixed yet, but std::common_reference_t<volatile int&, const int&> doesn't rely on its result.

Additional workarounds:

  • MSVC also sometimes computes _Cond_res<A&, A&&> incorrectly to A& when A is an array type. The result should be decayed.
  • MSVC computes the composite pointer of volatile T(*)[N] and const T(*)[N] to ill-defined result type T volatile (const volatile*)[N]. Currently my workaround is incomplete. A complete workaround may need to hack the whole computation in [conv.qual]/3.
  • DevCom-1627396 matters.

@frederick-vs-ja frederick-vs-ja requested a review from a team as a code owner February 25, 2022 02:34
@StephanTLavavej StephanTLavavej added the bug Something isn't working label Feb 25, 2022
stl/inc/concepts Outdated Show resolved Hide resolved
stl/inc/type_traits Outdated Show resolved Hide resolved
@StephanTLavavej
Copy link
Member

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 is_pod attempted to do) - that's bad for throughput, it's hard to know if the workaround is truly complete, and it accretes complexity as the language evolves. However, a compiler-specific, well-commented, well-tested, temporary workaround to a fundamental type trait that has been blocking a number of libcxx tests from running, seems like an entirely reasonable thing to do. (It's consistent with our usual practice of working around compiler bugs while reporting them and waiting for fixes.)

@StephanTLavavej

This comment was marked as resolved.

Copy link
Member

@CaseyCarter CaseyCarter left a 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.

@CaseyCarter CaseyCarter removed their assignment Mar 16, 2022
@StephanTLavavej StephanTLavavej self-assigned this Mar 18, 2022
@StephanTLavavej
Copy link
Member

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

@StephanTLavavej StephanTLavavej merged commit 8cc1601 into microsoft:main Mar 19, 2022
@StephanTLavavej
Copy link
Member

Thanks for improving this type traits machinery to be more correct than the compiler! 😹 🚀 🎉

@frederick-vs-ja frederick-vs-ja deleted the common-reference-workaround branch March 19, 2022 10:19
miscco added a commit to miscco/libcudacxx that referenced this pull request Jan 26, 2023
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
miscco added a commit to miscco/libcudacxx that referenced this pull request Feb 8, 2023
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
miscco added a commit to NVIDIA/libcudacxx that referenced this pull request Feb 13, 2023
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
miscco added a commit to miscco/libcudacxx that referenced this pull request Feb 14, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

<iterator>: std::contiguous_iterator<const volatile int*> == false because of volatile?
4 participants
  翻译: