-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Special errors for common trait object issues #38376
Comments
I've previously suggested the second one for a clippy lint. |
Returning a trait object by valueCode like this: fn foo() -> Iterator<Item = u32> { ... } Gives you this error:
It would be better if it contained the suggestion to |
Current output in order:
|
leaves me wondering why it can't be invoked. It would be great if the error message could say why. |
Output with #68377:
|
Tweak obligation error output - Point at arguments or output when fn obligations come from them, or ident when they don't - Point at `Sized` bound (fix #47990) - When object unsafe trait uses itself in associated item suggest using `Self` (fix #66424, fix #33375, partially address #38376, cc #61525) - Point at reason in object unsafe trait with `Self` in supertraits or `where`-clause (cc #40533, cc #68377) - On implicit type parameter `Sized` obligations, suggest `?Sized` (fix #57744, fix #46683)
After looking at this ticket again, I realized that we already handle the last case left, if and only if the types returned are "correct", but we don't if the return paths of the function body are |
There are a few common mistakes people make involving trait objects, where instead of getting a helpful error, they end up getting some error about how their trait doesn't implement
Sized
. This can be extremely confusing, and it doesn't given any guidance to help the user solve their actual issue.It would be great if we could just get special case error messages for each of these situations that tell the user how their problem can be solved.
Here are a few common cases I see often:
The trait is not in scope
A common pattern (shared by
Iterator
andFuture
for example) is to have parametric provided methods bounded bySelf: Sized
& an implementation ofTrait for Box<T> where T: Trait + ?Sized
.If you end up getting a
Box<Trait>
in a scope where you don't have the trait in scope, method resolution will deref your box, and try to call the method on the raw, dynamically sized trait object, which will result in an error about how'Trait + 'static: Sized' not satisfied
.A minimal example:
https://is.gd/2G5ywC
The actual solution to this is to import the trait into the scope in question, so that the Box's impl will be delegated to, instead of the raw object.
One wonders if there isn't a deeper solution to this problem, but at minimum we could recognize cases where you could instead delegate to the Box impl and suggest importing the trait instead.
You didn't mean to implement it for the trait object
Users who haven't fully internalized the idea of "parametric polymorphism" will often come upon the idea of providing a blanket impl, and write it like this:
Often,
Bar
is not object safe, and so you get aSized
issue. Sometimes,Bar
is object safe, and so you get an even more confusing error when you try to invoke a Foo method on a Bar type.Implementing a trait for an unsized trait object is almost never what you want to do to (I've never wanted to, at least). At very least, in the case where the trait is not object-safe, we could suggest that what you actually want is this:
The text was updated successfully, but these errors were encountered: