-
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
Implement workaround for LLVM-46269 by ensuring that constrained destructor appears after the unconstrained one #2630
Implement workaround for LLVM-46269 by ensuring that constrained destructor appears after the unconstrained one #2630
Conversation
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. |
// To test the correct specialization of _Defaultabox, this type must not be default constructible. | ||
non_trivially_destructible_input_iterator() = delete; |
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 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.
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for improving our Clang support! 😻 🐞 🎉 |
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.