-
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
error msg "Add
/AddAssign
(etc) is not implemented for the type _
" poor for beginners
#34297
Comments
Add
/AddAssign
(etc) is not implemented for the type _
poor for beginnersAdd
/AddAssign
(etc) is not implemented for the type _
" poor for beginners
I think we can print more than
We can also sneak in the literal which created the inference variable, but in the current |
After #35080, we now print |
As a beginner I stumbled upon this problem, but with integers, and a more complicated expression. The problem was much more clearly explained (what errors in the expression) when I replaced edit: Putting |
Current output:
We could maybe add some suggestions to cast from float to integer or vice versa. |
The casting suggestion could be added to |
…nikomatsakis Add filtering options to `rustc_on_unimplemented` - Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments. - Add a way to provide custom notes. - Tweak binops text. - Add filter to detect wether `Self` is local or belongs to another crate. - Add filter to `Iterator` diagnostic for `&str`. Partly addresses rust-lang#44755 with a different syntax, as a first approach. Fixes rust-lang#46216, fixes rust-lang#37522, CC rust-lang#34297, rust-lang#46806.
Current output:
|
CC #38564 |
Closing in favor of #38564. |
Reduced version of code encountered during a tutorial:
Compiler error message:
Namely, the error message says nothing about
i32
norf64
nor the use oflet x = 0;
, so a beginner really has no place to go for help here.Can we leverage the
on_unimplemented
functionality to provide better feedback in the case where one is mixingi32
andf64
? (Or does it not have a way to put in a more specific message depending on the types involved in this case?)There may be an issue for this elsewhere (we all know that our error messaging when type-inference goes to numeric-fallback), but the error message here was particularly bad, and I couldn't find an existing issue quickly, so I am filing this one to make sure this doesn't fall through the cracks.
The text was updated successfully, but these errors were encountered: