Closed cschreib closed 8 months ago
Minimal reproduction of the issue:
#include <compare>
struct operator_not_equal {
template<typename T, typename U>
constexpr bool operator()(const T& lhs, const U& rhs) const noexcept(noexcept(lhs != rhs))
requires(requires(const T& lhs, const U& rhs) { lhs != rhs; })
{
return lhs != rhs;
}
};
int main() {
operator_not_equal{}(1 <=> 1, 0);
return 0;
}
Yields:
<source>(9): error C7595: 'std::_Literal_zero::_Literal_zero': call to immediate function is not a constant expression
<source>(9): note: failure was caused by a read of a variable outside its lifetime
<source>(9): note: see usage of 'rhs'
<source>(14): note: see reference to function template instantiation 'bool operator_not_equal::operator ()<std::strong_ordering,int>(const T &,const U &) noexcept const' being compiled
with
[
T=std::strong_ordering,
U=int
]
Seems like a compiler bug:
!=
expression, the requires()
should have prevented instantiation of the function. Instead it passed, and the error occurred on instantiation.Reported here: https://developercommunity.visualstudio.com/t/Regression:-False-positive-C7595:-std::/10509214
NB: The expected behavior here is still a compilation error, but only as a "no matching call found for operator()
". The expected error enables conditional decomposition; while we cannot decompose 1 <=> 1 != 0
, snitch contains code to recover from this. This compiler bug is preventing the recovery from doing its job.
I will tag this as "not our bug" since the ball is in the camp of the MSVC team now. In https://github.com/snitch-org/snitch/pull/144 the offending test is disabled specifically for the affected MSVC compiler version.
This is not actually bug, but rather consequence of an intended change.
Thanks for the link! That's unfortunate, although it still seems to me that, as you put it, "requires lying" should really be seen as a bug.
I agree, but some people don't 🤷
I am currently trying to convince libc++ maintainers not to make the same change.
In testing the other branches I am working on I am hitting this failure with MSVC2022 build tools
Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33523 for x64
Just FYI. Maybe best to just remove the upper limit on MSVC version?
Thanks. I guess that'll keep failing until the bug report is addressed... I had left an explicit upper limit to avoid the risk of forgetting that the test is disabled. My hope was that it would be fixed quickly, but if not, as it appears, this may prove indeed to be a nuisance.
Next time GitHub bump the compiler version, we can remove the upper limit. Perhaps also reopen this ticket as a reminder that the problem still exists.
For the test/bug to be fixed, MSVC has to implement P2564 which was a late DR against C++20. Supposedly it was pretty hard to implement for Clang, and MSVC's constexpr engine is much more of a mess, so it might take a long while.
For the compilation check, you probably want to guard the test on __cpp_consteval >= 202211L
, rather than MSVC version.
MS STL refuses to back out the change, because the issue is in the compiler and e.g. clang-cl does have the required behaviour. libc++ followed MS STL, but they also use an interesting clang extension that means you can still sfinae on the behaviour (as long as you use Clang as the compiler).
From https://github.com/snitch-org/snitch/actions/runs/6781475887/job/18431859675.
The Windows pipeline worked fine last week, with MSVC 19.35.32217.1. Now, running the CI pipeline with MSVC 19.37.32825.0, we get this: