Implement #[rustc_must_implement_one_of] attribute

[WaffleLapkin]

This PR adds a new attribute — #[rustc_must_implement_one_of] that allows changing the "minimal complete definition" of a trait. It's similar to GHC's minimal {-# MINIMAL #-} pragma, though #[rustc_must_implement_one_of] is weaker atm.

Such attribute was long wanted. It can be, for example, used in Read trait to make transitions to recently added read_buf easier:

#[rustc_must_implement_one_of(read, read_buf)]
pub trait Read {
    fn read(&mut self, buf: &mut [u8]) -> Result<usize> {
        let mut buf = ReadBuf::new(buf);
        self.read_buf(&mut buf)?;
        Ok(buf.filled_len())
    }

    fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> {
        default_read_buf(|b| self.read(b), buf)
    }
}

impl Read for Ty0 {} 
//^ This will fail to compile even though all `Read` methods have default implementations

// Both of these will compile just fine
impl Read for Ty1 {
    fn read(&mut self, buf: &mut [u8]) -> Result<usize> { /* ... */ }
}
impl Read for Ty2 {
    fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ }
}

For now, this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it:

• Allow arbitrary requirements like a | (b & c)
• Allow multiple requirements like

  • #[rustc_must_implement_one_of(a, b)]
    #[rustc_must_implement_one_of(c, d)]

• Make it appear in rustdoc documentation
• Change the syntax?
• Etc

Eventually, we should make an RFC and make this (or rather similar) attribute public.

---

I'm fairly new to compiler development and not at all sure if the implementation makes sense, but at least it passes tests :)

[WaffleLapkin]

r? @Aaron1011

[danielhenrymantilla]

Quite glad to see the eq / ne etc. situation fixed that nicely 👌

Just a nit about favoring "(associated) function" terminology to "methods".

[bors]

☔ The latest upstream changes (presumably #90639) made this pull request unmergeable. Please resolve the merge conflicts.

[Aaron1011]

I think this can just be &[] instead of &[][..]

[WaffleLapkin]

[danielhenrymantilla]

Very disappointing; minimal repro: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=875b8d707eb70e293fc06d51eb6f26e0 — a type annotation at line 1201 does fix it, but without that a "wide pointer" field on one branch is not sufficient for a coercion to happen on other branches.

[WaffleLapkin]

Actually, even a one element tuple is enough to demonstrate this: (play)

[Aaron1011]

Can you rebase this against master?

[Aaron1011]

It looks like you need to mark the test with // check-pass

[WaffleLapkin]

This PR is currently broken because #90639 changed what values does is_implemented have. So the test correctly fails (by passing compilation). I haven't yet figured how to fix this.

[WaffleLapkin]

@Aaron1011 I rebased & fixed the problem, now it should work as expected again :')

[WaffleLapkin]

The test failed because order of items in a FxHashSet<Ident> changed. Isn't FxHashSet supposed to be deterministic?

And what is the right way to get items from it for error reporting then? We can access the original list there, instead of the hash set I think.

[WaffleLapkin]

@Aaron1011 I removed the use of HashSet so CI should spuriously fail anymore. I've also added a check that all function names are unique.

[danielhenrymantilla]

Modulo that last tiny nit, the new improvements look good to me! (EDIT: I still can't r stuff 😅)

[bors]

@danielhenrymantilla: 🔑 Insufficient privileges: Not in reviewers

[Aaron1011]

@bors r+

[bors]

📌 Commit 28edd7a has been approved by Aaron1011

[oxalica]

This reminds me the #[cfg()] syntax, which already defines a set of boolean operators.
Would it be more clear to be #[rustc_must_implement(any(a, b))] and can be extended to #[rustc_must_implement(all(any(a, b), any(c, d)))]?

[WaffleLapkin]

@oxalica personally I'd say that cfg syntax is quite hard to read. I've seen a proposal to change it to use && and || and IMO it's a good idea.

rustc_must_implement can be extended to use the old cfg syntax or a new one, though I think we should at least explore other possibilities. For example, since rustc_must_implement can only make the requirement stricter and it seems to be mostly needed when you have recursive default implementation, maybe something like #[requires] attribute is better suited for this:

trait Eq {
    #[requires(neq)]
    fn eq(&self, other: &Self) -> bool { !self.neq(other) }

    #[requires(eq)]
    fn neq(&self, other: &Self) -> bool { !self.eq(other) }
}

[oxalica]

@WaffleLapkin

@oxalica personally I'd say that cfg syntax is quite hard to read. I've seen a proposal to change it to use && and || and IMO it's a good idea.

I'm not really care about the detail of cfg syntax or if it need to be changed. I just think if we have two similar situations, it's better to always keep them consistent, and maybe changing them together, instead of inventing a new one in the new place.

trait Eq {
    #[requires(neq)]
    fn eq(&self, other: &Self) -> bool { !self.neq(other) }

    #[requires(eq)]
    fn neq(&self, other: &Self) -> bool { !self.eq(other) }
}

I don't like the word requires since it sounds like the semantic of "use/import neq" instead of "must impl", but well it's a bike-shedding issue.
As you said, this solution is specific for recursive default impls and cannot express something like #[must_implement(any(not(foo), bar))] trait Foo { .. } (defining foo implies defining bar). But I'm not sure if this complex case ever exists in real world.