<memory>: shared_ptr comparison (<=>)

[viccpp]

Describe the bug
Comparison of std::shared_ptrs fails. See the test case.

Command-line test case

C:\Temp>type repro.cpp
#include<compare>
#include<memory>

int main()
{
    std::shared_ptr<const int> p1;
    std::shared_ptr<void> p2;

    auto cmp = p1 <=> p2;
}

C:\Temp>cl /std:c++20 repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32215 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

repro.cpp
C:\opt\VC\include\memory(1778): error C2446: '<=>': no conversion from 'void *' to 'const int *'
C:\opt\VC\include\memory(1778): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast
repro.cpp(9): note: see reference to function template instantiation 'std::strong_ordering std::operator <=><const int,void>(const std::shared_ptr<const int> &,const std::shared_ptr<void> &) noexcept'
 being compiled

Expected behavior
Successful compilation at least.

Additional notes
This fails as well:

 const int *p1;
 void *p2;

 auto cmp = p1 <=> p2;

But both GCC and Clang compile this successfully!

[frederick-vs-ja]

This is a bug of MSVC. I think that Clang-cl would correctly accept such comparison.

DevCom-10334808 is reported, and I guess it's possiby a duplicated of a previously reported issue.

[viccpp]

This is a bug of MSVC.

For raw pointers - yes. But it can be worked around in shared_ptr comparison implementation. For example by conversion the pointers to const void * before comparison. Or maybe even to const volatile void *

[frederick-vs-ja]

Hmm... I think we may need to add workaround to three_way_comparable_with first, and then use compare_three_way or something like instead of unwrapped operator<=> in a large portion of MSVC STL.

This is definitely doable, but damages throughput. I'm not sure whether this is acceptable by maintainers.

[viccpp]

Correctness first! :-)

[frederick-vs-ja]

A clean and complete workaround seems available for shared_ptr, but not unique_ptr... Because of the arbitrability of unique_ptr::pointer, it seems that we can't achieve a complete workaround.