-
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
<memory>
: Workaround for MSVC bug on operator<=>
(shared_ptr
only)
#3647
<memory>
: Workaround for MSVC bug on operator<=>
(shared_ptr
only)
#3647
Conversation
If the workaround is very much wanted, think we can specialize the workaround. But I'd gave up and waited for the compiler fix instead. |
I audited the library to find all other affected locations:
#include <cassert>
#include <compare>
#include <iterator>
#include <memory>
#include <optional>
using namespace std;
struct NoDeleter {
template <typename T>
void operator()(const T&) {}
};
int main() {
int arr[2]{};
const int* p = arr;
void* q = arr + 1;
static_assert(three_way_comparable_with<const int*, void*>);
assert(compare_three_way{}(p, q) == strong_ordering::less);
assert(basic_const_iterator{p} <=> q == strong_ordering::less);
assert((unique_ptr<const int, NoDeleter>{p} <=> unique_ptr<void, NoDeleter>{q} == strong_ordering::less));
assert(optional{p} <=> optional{q} == strong_ordering::less);
assert(optional{p} <=> q == strong_ordering::less);
}
Therefore, I believe that limiting the workaround to |
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for reporting this compiler bug and adding a workaround to the most affected location! 🐞 🛸 🛠️ |
Fixes #3646.
I think similar handling for
unique_ptr
is definitely wanted, but it seems that we can't achieve a complete workaround forunique_ptr
due to the arbitrability ofunique_ptr::pointer
.