Confusing error when using CoercePointee

[RalfJung]

Code

#![feature(derive_coerce_pointee)]
use std::marker::CoercePointee;
use std::rc::Rc;

#[repr(transparent)]
#[derive(CoercePointee)]
struct RcWithId<T: ?Sized> {
    inner: Rc<(i32, Box<T>)>,
}

Current output

error[E0277]: the trait bound `Box<T>: Unsize<Box<__S>>` is not satisfied
 --> src/main.rs:6:10
  |
6 | #[derive(CoercePointee)]
  |          ^^^^^^^^^^^^^ the trait `Unsize<Box<__S>>` is not implemented for `Box<T>`
  |
  = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information
  = note: required for `Rc<(i32, Box<T>)>` to implement `DispatchFromDyn<Rc<(i32, Box<__S>)>>`
  = note: this error originates in the derive macro `CoercePointee` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Box<T>: Unsize<Box<__S>>` is not satisfied
 --> src/main.rs:6:10
  |
6 | #[derive(CoercePointee)]
  |          ^^^^^^^^^^^^^ the trait `Unsize<Box<__S>>` is not implemented for `Box<T>`
  |
  = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information
  = note: this error originates in the derive macro `CoercePointee` (in Nightly builds, run with -Z macro-backtrace for more info)

Desired output

Something that does not mention internal things like `Unsize` or `__S`

Rationale and extra context

No response

Other cases

Rust Version

current nightly

Anything else?

No response

[Darksonn]

I just learned of this issue.

Thoughts @dingxiangfei2009? Could we utilize the traits from #136107 to emit better errors?

[dingxiangfei2009]

@Darksonn honestly I was pondering about this problem yesterday but I wasn't aware of this ticket that was filed.

The check can definitely be performed with the new trait. The next step I will need to look into, is to devise a method to suppress the errors when checks with CoercePointee have failed.

Or I suspect the better way could be, when the coherence check for DispatchFromDyn and CoerceUnsize is initiated, the check would attempt to determine if a CoercePointee is indeed to be derived on the target and present the error with the correct wording intended for CoercePointee accordingly. I will start with this approach first.