assert_receiver_is_total_eq not implemented for const usage

[leonardo-m]

If I try to use == among an user-defined struct in a const function, it seems I have to implement PartialEq::eq and PartialEq::ne, and Eq. But when I try to implement Eq it gives this error:

error: const trait implementations may not use non-const default functions
...
= note: `assert_receiver_is_total_eq` not implemented

That isn't documented. The stdlib comment says "This should never be implemented by hand.". What's the solution for this situation?

[oli-obk]

fun... cc @rust-lang/wg-const-eval

while there are fixes for this (an attribute on the trait decl), none are great at present.

I think for now, const trait impls must impl that method, even if that is annoying

[RalfJung]

I am confused. What is even causing the error? Eq has no methods...

... oh, it does:

pub trait Eq: PartialEq<Self> {
    // this method is used solely by #[deriving] to assert
    // that every component of a type implements #[deriving]
    // itself, the current deriving infrastructure means doing this
    // assertion without using a method on this trait is nearly
    // impossible.
    //
    // This should never be implemented by hand.
    #[doc(hidden)]
    #[no_coverage] // rust-lang/rust#84605
    #[inline]
    #[stable(feature = "rust1", since = "1.0.0")]
    fn assert_receiver_is_total_eq(&self) {}
}

So making that a const fn is not enough?

(I can't even parse that comment, what does it mean for a type to "implement #[deriving]"? Do they mean "implement Eq"? Also isn't the attribute called "derive" -- was is "#[deriving]"?)

[oli-obk]

You can't make default methods const fn. Well, you can, there is a horribly hacky attribute that we definitely don't want to use in libcore yet.