trait bound not satisfied "sealed trait" detection is too eager

[mattfbacon]

Code

mod x {
    pub trait A {}
    pub trait B: A {}
    
    pub struct C;
    impl B for C {}
}

Current output

error[E0277]: the trait bound `C: A` is not satisfied
 --> src/lib.rs:6:16
  |
6 |     impl B for C {}
  |                ^ the trait `A` is not implemented for `C`
  |
help: this trait has no implementations, consider adding one
 --> src/lib.rs:2:5
  |
2 |     pub trait A {}
  |     ^^^^^^^^^^^
note: required by a bound in `B`
 --> src/lib.rs:3:18
  |
3 |     pub trait B: A {}
  |                  ^ required by this bound in `B`
  = note: `B` is a "sealed trait", because to implement it you also need to implement `x::A`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it

For more information about this error, try `rustc --explain E0277`.

Desired output

error[E0277]: the trait bound `C: A` is not satisfied
 --> src/lib.rs:6:16
  |
6 |     impl B for C {}
  |                ^ the trait `A` is not implemented for `C`
  |
help: this trait has no implementations, consider adding one
 --> src/lib.rs:2:5
  |
2 |     pub trait A {}
  |     ^^^^^^^^^^^
note: required by a bound in `B`
 --> src/lib.rs:3:18
  |
3 |     pub trait B: A {}
  |                  ^ required by this bound in `B`

For more information about this error, try `rustc --explain E0277`.

Rationale and extra context

In this case, the note does not apply, because in the context where we impl B for C, we could also impl A for C, so the trait may match the pattern of a sealed trait, but it is not sealed to us in this context.

Other cases

Rust Version

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Anything else?

Seems this implementation was too eager: 717c481

[yuk1ty]

@rustbot claim

[yuk1ty]

I believe this one has already been resolved #143431 by @xizheyin . However, I opened a pull request to ensure the case has been exactly resolved.