You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
impl dyn Trait on an auto trait produces a confusing diagnostic #85026
error[E0118]: no nominal type found for inherent implementation
--> src/lib.rs:1:6
|
1 | impl dyn Unpin {}
| ^^^^^^^^^ impl requires a nominal type
|
= note: either implement a trait on it or create a newtype to wrap it instead
This is rather confusing. It's not immediately clear what the difference between impl dyn Unpin and this working code is (playground):
traitA{}impldynA{}
Since impl dyn A is accepted, the user might be confused why dyn A would be considered a nominal type when dyn Unpin isn't. The real reason why impl dyn Unpin is an error is because it is an impl block for a type [edit: a dynamically dispatched auto trait] from another crate, which should be handled by E0116.
Ideally the output should look like:
error[E0116]: cannot define inherent `impl` for a type outside of the crate where the type is defined
--> src/lib.rs:1:1
|
1 | impl dyn Unpin {}
| ^^^^^^^^^^^^^^^^^ impl for type defined outside of crate.
|
= note: define and implement a trait or new type instead
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (playground):
use std::panic::UnwindSafe;impldynCopy{}impldynUnwindSafe{}
error[E0116]: cannot define inherent `impl` for a type outside of the crate where the type is defined
--> src/lib.rs:3:1
|
3 | impl dyn Copy {}
| ^^^^^^^^^^^^^^^^ impl for type defined outside of crate.
|
= note: define and implement a trait or new type instead
error[E0118]: no nominal type found for inherent implementation
--> src/lib.rs:4:6
|
4 | impl dyn UnwindSafe {}
| ^^^^^^^^^^^^^^ impl requires a nominal type
|
= note: either implement a trait on it or create a newtype to wrap it instead
Note that this still happens with auto traits in the same crate, but in this case E0116 wouldn't be applicable (playground):
#![feature(auto_traits)]
auto traitX{}impldynX{}
error[E0118]: no nominal type found for inherent implementation
--> src/lib.rs:4:6
|
4 | impl dyn X {}
| ^^^^^ impl requires a nominal type
|
= note: either implement a trait on it or create a newtype to wrap it instead
The diagnostic is still confusing in this case and could be rewritten to explicitly point out that impl dyn AutoTrait is not allowed.
changed the title [-]`impl dyn Trait` on a trait from another crate produces a confusing diagnostic[/-][+]`impl dyn Trait` on an auto trait from another crate produces a confusing diagnostic[/+]on May 7, 2021
changed the title [-]`impl dyn Trait` on an auto trait from another crate produces a confusing diagnostic[/-][+]`impl dyn Trait` on an auto trait produces a confusing diagnostic[/+]on May 7, 2021
Activity
PatchMixolydic commentedon May 7, 2021
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (playground):
Note that this still happens with auto traits in the same crate, but in this case
E0116wouldn't be applicable (playground):The diagnostic is still confusing in this case and could be rewritten to explicitly point out that
impl dyn AutoTraitis not allowed.@rustbot modify labels: +D-confusing +F-auto_traits
[-]`impl dyn Trait` on a trait from another crate produces a confusing diagnostic[/-][+]`impl dyn Trait` on an auto trait from another crate produces a confusing diagnostic[/+][-]`impl dyn Trait` on an auto trait from another crate produces a confusing diagnostic[/-][+]`impl dyn Trait` on an auto trait produces a confusing diagnostic[/+]Rollup merge of rust-lang#88525 - notriddle:notriddle/coherence-dyn-a…