Fixes https://github.com/llvm/llvm-project/issues/43670
From https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0768r1.pdf :
The relational and equality operators for the comparison category types are specified with an
anonymous parameter of unspecified type. This type shall be selected by the implementation such
that these parameters can accept literal 0 as a corresponding argument. [Example: nullptr_t
satisfies this requirement. — end example] In this context, the behavior of a program that supplies
an argument other than a literal 0 is undefined
So after this patch we will accept not literal 0 but consteval zero like
#include <compare>
consteval int test() { return 0;}
auto b = 1 <=> 2 < test();But before we accepted nullptr. So I guess it's fine and the behavior is undefined in the both cases.
Oh, I see that we rejected nullptr: https://github.com/llvm/llvm-project/blob/93a04a0591c1958d5344f3541157fbd8b8ff7370/libcxx/test/std/language.support/cmp/cmp.categories.pre/zero_type.verify.cpp
That code was accepted. Yes, the probability of it in reality is much lower than auto b = 1 <=> 2 < (1-1). But I think (1-1) is also low enough...
#include <compare>
consteval int test() { return 0;}
auto b = 1 <=> 2 < (int std::_CmpUnspecifiedParam::*)nullptr;
Richard Smith and I have talked about creating a special type in Clang to use here.
I think we should investigate this approach more thoroughly before going down the path suggested here.
As is, your change makes the number of values and types accepted as an argument to _CmpUnspecifiedParam MUCH larger.
Before, it would only accept the _LITERAL_ zero, now it accepts anything that evaluates to zero, including (0 + 42 - 42), foo(), etc.
So this makes the library much less conforming than it was. This cannot proceed as is.
Though I grant it's very frustrating that the warning is triggered here. But we'll need Clang's help to resolve that.