-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
E0412 is correct but E0782 is emitted (in trait definitions) #116434
Comments
@rustbot claim |
It looks like #119752 (in the queue) changes this to E0038 without a suggestion (for edition 2021):
A suggestion to Do you have any links or can share how this is tripping up other users? |
Ah, apparently it's possible to produce multiple suggestions. I'll poke at it and see what comes out. |
It's been a while, but what I saw on the Discord went something like this: trait DbHandle {
/* irrelevant, but not object safe */
}
// Some lines away...
trait DbInterface {
// (presumably assuming the namespaces don't overlap)
type DbHandle;
fn handle() -> DbHandle;
} The user then gets the "please add The compiler then tells them "sorry you can't |
The problematic The type (trait) DbHandle is in scope, so I don't think E0412 (cannot find type in this scope) is correct. If it provides the correct suggestion though, it would definitely be an improvement to include that suggestion in the output. I don't see a clear way to get there from the E0038 code path though. :( |
Making some progress on this, currently blocked on #120164 |
@rustbot label -D-invalid-suggestion |
blocked on #120275 |
…rors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? `@fmease`
…rors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? ``@fmease``
I have a PR ready to go for this that adds the |
…rors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? `@fmease`
…rors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? ``@fmease``
…rors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? ```@fmease```
Rollup merge of rust-lang#120530 - trevyn:issue-116434, r=compiler-errors Be less confident when `dyn` suggestion is not checked for object safety rust-lang#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in rust-lang#116434 r? ```@fmease```
Rollup merge of rust-lang#121111 - trevyn:associated-type-suggestion, r=davidtwco For E0038, suggest associated type if available Closes rust-lang#116434
Code
Current output
Desired output
Obviously this isn't helpful, as
Clone
isn't object safe. The correct error isE0412
:Rationale and extra context
E0412
is correctly emitted if the associated type name is changed to not collide with any traits currently in scope. So:Errors as expected.
I've also seen this confuse new users "in the wild" on Rustcord - that's what originally inspired me to file this issue.
Other cases
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: