Mark defaulted PartialEq/PartialOrd methods as const

[ecstatic-morse]

WIthout it, const impls of these traits are unpleasant to write. I think this kind of change is allowed now. although it looks like it might require some Miri tweaks. Let's find out.

r? @fee1-dead

[fee1-dead]

cc @oli-obk per https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/default_method_body_is_const

Overview of #[default_method_body_is_const]

This attribute is currently a placeholder. When the const_trait_impl feature gets stabilized it should be changed to something else (preferably new syntax). When marked on a trait method with a default body, we perform checks on it as if it were a const function. This allows users to have traits that are easier to write const impls for.

trait PartialEq {
    fn eq(&self, other: &Self) -> bool;

    #[default_method_body_is_const]
    fn ne(&self, other: &Self) -> bool {
        !self.eq(other) // call to self.eq is allowed in const context because `eq` has a const implementation
    }
}

Note that we cannot use const fn as an indicator for default_method_body_is_const, because it can contradict with future extensions such as const trait fns which always require implementations to be const.

[oli-obk]

Nominating for T-lang discussion.

We want to experimentally and unstably use this never-to-be-stabilized attribute. I'm assuming we're going to add something (e.g. partial or default impls) in the future that allows us to remove the attribute as you could mark such impls as const then. In any case, this is all unstable and reversible until we stabilize the ability for users to call or write const trait impls

[ecstatic-morse]

Ah, I didn't think this was novel. My bad. This came up as part of #91386, and it's basically the most obvious use-case for #[default_method_body_is_const], so it's a fine place to start.

I don't know what's causing miri to fail though. I'm guessing it's not correctly resolving the method to the defaulted one?

[Mark-Simulacrum]

@oli-obk Could you expand a little on the ask from T-lang? " In any case, this is all unstable and reversible until we stabilize the ability for users to call or write const trait impls" makes it sound like there is no risk to this PR, so it's not clear that a discussion is necessary -- if it is, I feel like a concrete question to answer would be helpful to make sure that discussion tries to answer it.

[oli-obk]

The question is: are we going to add something (e.g. partial or default impls) in the future that allow us to remove the attribute as you could then mark such impls as const?

The reason I ask is that we don't really gate this feature, except for the gate that allows you to call const trait impls. Were we to stabilize any const traits that use this feature, we'd lock ourselves into requiring that we'll have such a feature

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. This sounds reasonable to us, as long as it's documented in the tracking issue for const trait impls as a gating consideration for stabilization (e.g. in the top post of such a tracking issue).

[oli-obk]

The tracking issue of const trait impls (#67792) tracks this in the main issue comment

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit dc18d50 has been approved by oli-obk

[ecstatic-morse]

@bors r-

This is broken, and I still don't know that the bug is.

[matthiaskrgr]

Failed in a rollup: #91937 (comment)

[fee1-dead]

Consider rebasing on top of master since the fix (#92001) has landed.

[fee1-dead]

@bors r=oli-obk

[bors]

📌 Commit 2049287 has been approved by oli-obk