[Bug c++/94162] ICE [neg] bad return type in defaulted <=>

["dacamara.cameron at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162

--- Comment #2 from Cameron <dacamara.cameron at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> It isn't clear to me what exactly disallows it, perhaps
> http://eel.is/c++draft/class.spaceship#2.2
> ?
> For auto return type
> http://eel.is/c++draft/class.spaceship#4
> defines what return type it should have.
> If the explicit return type isn't auto, but is one of the
> std::{strong,weak,partial}_ordering, we don't ICE and accept it, should we
> and what behavior should it have?
> #include <compare>
> struct S {
>   float a;
>   std::strong_ordering operator<=>(const S&) const = default;
> };
> bool b = S{} < S{};
> struct T {
>   std::partial_ordering operator<=>(const T&) const = default;
> };
> bool c = T{} < T{};
> For S, the auto return type would be std::partial_ordering and in the
> generated body we just assume the floats will not be unordered.
> So, for bool, shall it be accepted and handled some way, or shall it be
> deleted, or result in immediate error (ill-formed)?
> What about even weirder types (say float or int * or some arbitrary class)?

As you point out, the standard isn't clear about what to do in the case where
the comparison function does not return 'auto' or any of the comparison type
forms.

Our compiler (MSVC) now opts to issue a diag at the point of definition when a
nonsense return type is specified.  There is, unfortunately, room for
implementation divergence here.

Not ICEing--as we once did--is a good start though :).