-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Error messages can be ambiguous between types and type parameters #81971
Comments
For the benefit of anyone learning Rust that might encounter this ticket while trying to understand how to fix their code, what is needed is to constrain the type parameter with fn test<T: Into<i32>>(t: T) -> i32 {
5_i32 + t.into()
} |
There are two different problems that need to be handled here. The first error is slightly misleading and can only be solved by knowing about the
We should do the same for E0277. |
For what it's worth, I believe this error actually came from https://stackoverflow.com/questions/66082378/how-to-add-trait-bound-to-a-non-generic-type (which was linked on Reddit). I just assumed that they ran into the issue (it wasn't clear from context/phrasing). This isn't relevant to the issue itself, though. |
You could also write |
After thinking about it, I feel like it's probably best for rustc to always suggest this form. It'd probably make sense to have a clippy lint suggesting rewriting this to the more idiomatic |
There's a draft PR for that: rust-lang/rust-clippy#6620 |
@leo60228 one consideration is that clippy lints don't always necessarily trigger and having multiple errors can be confusing to people (not everyone reads everything before figuring out what the problem is). Because of that I would also like to extend the existing error to account for this case. :) |
…n, r=petrochenkov In some limited cases, suggest `where` bounds for non-type params Partially address rust-lang#81971.
…n, r=petrochenkov In some limited cases, suggest `where` bounds for non-type params Partially address rust-lang#81971.
The first case is now handled, the second case of type params masking types is yet to be resolved. I think at least pointing out that that has happened on all E0277 by visiting every type involved in the obligation and seeing if there's any type parameter with the same name as another type in scope and emitting a note explaining that that's what's happening would improve the situation. |
Current output for the first case:
and for the second case
|
Someone I know was learning Rust as a beginner. They defined a function like this:
This resulted in an error:
Based on this error, they attempted to add an
i32: From<T>
bound:This leads to a different, very misleading error:
#[warn(non_camel_case_types)]
can give a hint, but I think that the error message should stand on its own. In addition, they appear to have added#![allow(non_camel_case_types)]
for unrelated reasons.Meta
rustc --version --verbose
: (N/A, on playground)The text was updated successfully, but these errors were encountered: