Better error message for why ~/@/&Trait doesn't automatically implement Trait

[bblum]

Consider the following:

trait Foo {
    fn foo();
}
impl Foo for () {
    fn foo() { }
}
fn main() {
    (&() as &Foo).foo();
}

The error is:

error: type `&Foo<no-bounds>` does not implement any method in scope named `foo`

The reason trait types do not automatically implement their own traits is that if the trait interface has a Self type variable, it does not make sense for it to be called in a heterogeneous way (e.g., if instantiating fn eq(&self, other: &Self) with int-as-Eq as the first thing, it makes no sense to pass a str-as-Self as the second.

But if the trait has no such problematic interface functions, it should (apparently doesn't yet, but should in the future -- @nikomatsakis) be possible for the user to write an impl with stub methods that do dynamic dispatch.

So, I wish for either (a) a special-case span_note that accompanies this error that instructs the user to write stubs, or (b) recognising a non-problematic trait interface that can be auto-implemented, permitting that, and having a special-case span_note that explains why not in the problematic case.

[Kimundi]

Could also maybe have a deriving mode. #[deriving_self_trait] or so.

[thestinger]

I think auto-implementing it would be much better than deriving. We'll still need to improve the error messages to explain that Self is the issue.

[flaper87]

Visiting for triage. The example in the report is still valid.

[japaric]

Triage: Currently ICEs (see #18490), but the ICE should be fixed by #18527.

Can this be closed after #18527? We now forbid (and diagnose) creating trait objects for traits that are not object-safe.

cc @aturon @bkoropoff

[nrc]

We can probably close this, the intention is that &Foo will implement Foo, and in the mean time, the error should be prevented by the object safety rules.

[steveklabnik]

Yes, object safety plus the soon-to-land (if it dind't already) trait object implements the trait makes this moot.