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

Implement workaround for LLVM-46269 by ensuring that constrained destructor appears after the unconstrained one #2630

Merged
merged 2 commits into from
Apr 4, 2022

Conversation

cpplearner
Copy link
Contributor

This implements workaround for LLVM-46269 ("Only first destructor is considered when constraints are used").

If the constrained (and defaulted) destructor comes first, clang-cl uses it unconditionally, even if its constraints are not satisfied. This leads to an error when the defaulted destructor is implicitly deleted (due to a non-trivially-destructible member).

By moving the constrained destructor after the unconstrained one (which is always valid, but is non-trivial), this patch sidesteps the abovementioned error.

This is suboptimal, because this makes the affected types never trivially destructible when compiled with clang-cl. A perfect fix would need to use something akin to the existing _Optional_destruct_base, which I assume that we want to avoid.

@cpplearner cpplearner requested a review from a team as a code owner April 1, 2022 09:23
@CaseyCarter CaseyCarter added the bug Something isn't working label Apr 1, 2022
@CaseyCarter CaseyCarter self-assigned this Apr 1, 2022
tests/std/tests/P0896R4_common_iterator/test.cpp Outdated Show resolved Hide resolved
tests/std/tests/P0896R4_common_iterator/test.cpp Outdated Show resolved Hide resolved
tests/std/tests/P0896R4_common_iterator/test.cpp Outdated Show resolved Hide resolved
tests/std/tests/P0896R4_views_join/test.cpp Outdated Show resolved Hide resolved
@CaseyCarter
Copy link
Member

Thanks bunches for jumping on this so quickly. I've added this PR to my list of things to ensure are in the 16.11 backport.

@CaseyCarter CaseyCarter removed their assignment Apr 1, 2022
Comment on lines +482 to +483
// To test the correct specialization of _Defaultabox, this type must not be default constructible.
non_trivially_destructible_input_iterator() = delete;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised that this doesn't trigger compiler warnings about "this class has no constructors" (usually I'd expect to see an (int, int) constructor or something similar to avoid this), but no change requested as there are apparently no test-breaking warnings.

@StephanTLavavej StephanTLavavej self-assigned this Apr 1, 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 added the ranges C++20/23 ranges label Apr 4, 2022
@StephanTLavavej StephanTLavavej merged commit e7f5b27 into microsoft:main Apr 4, 2022
@StephanTLavavej
Copy link
Member

Thanks for improving our Clang support! 😻 🐞 🎉

@cpplearner cpplearner deleted the workaround-llvm-46269 branch April 5, 2022 05:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ranges C++20/23 ranges
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants