Skip to content
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

Closed
withoutboats opened this issue Dec 14, 2016 · 6 comments · Fixed by #70998
Closed

Special errors for common trait object issues #38376

withoutboats opened this issue Dec 14, 2016 · 6 comments · Fixed by #70998
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@withoutboats
Copy link
Contributor

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 and Future for example) is to have parametric provided methods bounded by Self: Sized & an implementation of Trait 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:

trait Foo {
    fn bar(&self) where Self: Sized { }
}

impl<F: Foo + ?Sized> Foo for Box<F> { }

impl Foo for () { }

fn foo() -> Box<Foo> { Box::new(()) }

mod bar {
    use foo;

    fn bar() {
        foo().bar();
    }
}

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:

trait Foo { }

trait Bar: Sized { }

impl Foo for Bar { }

Often, Bar is not object safe, and so you get a Sized 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:

impl<T> Foo for T where T: Bar { }
@durka
Copy link
Contributor

durka commented Dec 15, 2016

I've previously suggested the second one for a clippy lint.

@withoutboats
Copy link
Contributor Author

Returning a trait object by value

Code like this:

fn foo() -> Iterator<Item = u32> { ... }

Gives you this error:

the trait bound `std::iter::Iterator<Item=u32> + 'static: std::marker::Sized` is not satisfied

It would be better if it contained the suggestion to Box the return type, and maybe said something about trait objects in addition to talking about "Sized"

@Mark-Simulacrum Mark-Simulacrum added the A-diagnostics Area: Messages for errors, warnings, and lints label May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@estebank
Copy link
Contributor

estebank commented Mar 6, 2019

Current output in order:

error: the `bar` method cannot be invoked on a trait object
  --> src/main.rs:15:15
   |
15 |         foo().bar();
   |               ^^^
   |
   = note: another candidate was found in the following trait, perhaps add a `use` for it:
           `use Foo;`
error[E0038]: the trait `Bar` cannot be made into an object
 --> src/lib.rs:5:6
  |
5 | impl Foo for Bar { }
  |      ^^^ the trait `Bar` cannot be made into an object
  |
  = note: the trait cannot require that `Self : Sized`
error[E0277]: the size for values of type `(dyn std::iter::Iterator<Item=u32> + 'static)` cannot be known at compilation time
 --> src/lib.rs:1:13
  |
1 | fn foo() -> Iterator<Item = u32> { panic!() }
  |             ^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `(dyn std::iter::Iterator<Item=u32> + 'static)`
  = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
  = note: the return type of a function must have a statically known size

@estebank estebank added D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 11, 2019
@gilescope
Copy link
Contributor

error: the `xxx` method cannot be invoked on a trait object

leaves me wondering why it can't be invoked. It would be great if the error message could say why.

@estebank
Copy link
Contributor

estebank commented Feb 1, 2020

Output with #68377:

error: the `bar` method cannot be invoked on a trait object
  --> file.rs:15:15
   |
2  |     fn bar(&self) where Self: Sized { }
   |                               ----- this has a `Sized` requirement
...
15 |         foo().bar();
   |               ^^^
   |
   = note: another candidate was found in the following trait, perhaps add a `use` for it:
           `use Foo;`
error[E0038]: the trait `Bar` cannot be made into an object
 --> file.rs:5:6
  |
3 | trait Bar: Sized { }
  |       ---  ----- ...because it requires `Self: Sized`
  |       |
  |       this trait cannot be made into an object...
4 |
5 | impl Foo for Bar { }
  |      ^^^ the trait `Bar` cannot be made into an object

bors added a commit that referenced this issue Feb 4, 2020
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)
@estebank
Copy link
Contributor

estebank commented Apr 10, 2020

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 !. Pushed #70998 that handles that last case. After that PR is merged, this will be the output:

Screen Shot 2020-04-11 at 11 35 06 AM

Screen Shot 2020-04-11 at 11 36 41 AM

@bors bors closed this as completed in 24fb393 Apr 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-newcomer-roadblock Diagnostics: Confusing error or lint; hard to understand for new users. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants