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

Print better auto-trait diagnostics when opaque return type is involved #67117

Closed
Aaron1011 opened this issue Dec 7, 2019 · 1 comment · Fixed by #66463
Closed

Print better auto-trait diagnostics when opaque return type is involved #67117

Aaron1011 opened this issue Dec 7, 2019 · 1 comment · Fixed by #66463

Comments

@Aaron1011
Copy link
Contributor

@Aaron1011 Aaron1011 commented Dec 7, 2019

The following code: (playground)

fn is_send<T: Send>(_val: T) {}
fn bar() -> impl Copy { 0 as *const () }

fn main() {
    is_send(bar());
}

gives the following error message:

error[E0277]: `*const ()` cannot be sent between threads safely
 --> src/main.rs:5:5
  |
1 | fn is_send<T: Send>(_val: T) {}
  |    -------    ---- required by this bound in `is_send`
...
5 |     is_send(bar());
  |     ^^^^^^^ `*const ()` cannot be sent between threads safely
  |
  = help: within `impl std::marker::Copy`, the trait `std::marker::Send` is not implemented for `*const ()`
  = note: required because it appears within the type `impl std::marker::Copy`

There are a couple of problems here:

  1. We refer to impl std::marker::Copy within mentioning where it's defined. Since auto traits 'leak through' impl trait, it would probably be a good idea to reference the function where it's defined to help disambiguate between multiple distinct impl SomeTrait types.
  2. We use the generic 'within' terminology, which doesn't really make that make much sense when referring to impl trait types. Since we're already exposing the underlying type in the error message, we might want to say something like:

'note: the anonymous return type impl Copy of function bar (with underlying type *const ()) does not implement std::marker::Send.'

@Aaron1011

This comment has been minimized.

Copy link
Contributor Author

@Aaron1011 Aaron1011 commented Dec 11, 2019

#66463 should make us start referencing the defining span of the opaque type, which will help with this.

Centril added a commit to Centril/rust that referenced this issue Jan 10, 2020
…e-types, r=Centril

Point at opaque and closure type definitions in type errors

Fixes rust-lang#57266, fixes rust-lang#67117.
@bors bors closed this in aabb037 Jan 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.