Better error reporting for T: ?Sized types when impl Receiver for MyType<T> is implicitly sized · Issue #134390 · rust-lang/rust (original) (raw)

Originally from @adetaylor:

I'm looking for advice on the diagnostics around the Sizedness of a receiver, and I'm hoping @estebank can advise (or of course anyone else @wesleywiser @compiler-errors ).

The background (for Esteban):

• This is the tracking issue for "arbitrary self types v2", which allows methods like this:
  impl Foo {
  fn bar(self: MySmartPtr) {} // note type of self
  }
• The key part of this is that types (such as MySmartPtr, above) which wish to act as method receivers must implement a new trait Receiver
• Before writing the RFC, I happened to make a mistake which I think might be quite common, so in the Diagnostics section of the RFC I proposed adding a diagnostic specifically for this case (the second bullet in that linked section).

The case I want to generate an error for: see this code but, in short, someone implements Receiver for T but not T: ?Sized.

Questions. Even partial answers to some questions might point me in the right direction.

Overall approach

1. I can quite easily get hold of an unmet obligation for why the type of self doesn't implement Receiver. But how can I determine if some missing ?Sized bound is the problem?
   a. Re-run the resolution process with some simulated fake sized Self type? See if the obligation resolves in that case, and if so, show a diagnostic.
   b. Simulate that some impl<T> Receiver for T block is actually impl <T: ?Sized> Receiver for T, elsewhere in the program or even in another crate. See if the obligation resolves in that case, and if so, show a diagnostic.
   c. Suggest "ensure any Receiver implementations cover !Sized" without actually checking that this is the problem. This might give lots of false positives.

@adetaylor: I've split this out into its own issue. Let's try to avoid discussion on tracking issues. It's really not the purpose of a tracking issue, and we've locked tracking issues in the past for exactly the same reason (it often pings like... 40 people who are subscribed to the issue).

These days tracking issues carry the note:

As with all tracking issues for the language, please file anything unrelated to implementation history, that is: bugs and design questions, as separate issues as opposed to leaving comments here. The status of the feature should also be covered by the feature gate label. Please do not ask about developments here.