-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 message for uninferrable type #38812
Comments
#36554 is aimed at the following case:
The case in this issue is slightly different. |
I think it's basically the same underlying problem: when we are unable to infer a type, we should be as helpful as we can in telling you (a) what type we are failing to infer and (b) how can you specify it yourself. #36554 really just took a baby step by providing you at least the name of the type parameter. But it's true it was targeting the case of calling a fn. |
So I have a plan for how to solve this. I have been talking to @cengizio who is going to take a stab at implementing it, but I wanted to write out the outlines here for future reference. Roughly speaking, the idea is that when we have an error that we need more type info about some type variable So the idea is that before we print the current message, we will try each of these heuristics (for now only local variables, but hopefully we'll grow more later). If we find a good suggestion for where to annotate, great, we can give a better error. Otherwise we fallback to the current one. This current error is reported in the function
Each type will potentially contain other inferences and so forth, so once we fetch the type for a To see whether this type includes If we find it, then we can give an error pointing at the local variable, saying something like |
Hello @nikomatsakis! Thanks again for mentoring me on rust internals 😉 I started working on this. |
My PR seems to be failing only for Investigating now |
Improve error message for uninferrable types rust-lang#38812 Hello, I tried to improve the error message for uninferrable types. The error code is `E0282`. ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:11 | 2 | let x = vec![]; | - ^^^^^^ cannot infer type for `T` | | | consider giving `x` a type | = note: this error originates in a macro outside of the current crate ``` and ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:15 | 2 | let (x,) = (vec![],); | ---- ^^^^^^ cannot infer type for `T` | | | consider giving a type to pattern | = note: this error originates in a macro outside of the current crate ``` Rust compiler now tries to find uninferred `local`s with type `_` and adds them into the error message. I'm probably wrong on wording that I used. Please feel free to suggest better alternatives. Thanks @nikomatsakis for mentoring 🍺 Any comments/feedback is more than welcome! Thank you
Improve error message for uninferrable types rust-lang#38812 Hello, I tried to improve the error message for uninferrable types. The error code is `E0282`. ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:11 | 2 | let x = vec![]; | - ^^^^^^ cannot infer type for `T` | | | consider giving `x` a type | = note: this error originates in a macro outside of the current crate ``` and ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:15 | 2 | let (x,) = (vec![],); | ---- ^^^^^^ cannot infer type for `T` | | | consider giving a type to pattern | = note: this error originates in a macro outside of the current crate ``` Rust compiler now tries to find uninferred `local`s with type `_` and adds them into the error message. I'm probably wrong on wording that I used. Please feel free to suggest better alternatives. Thanks @nikomatsakis for mentoring 🍺 Any comments/feedback is more than welcome! Thank you
Improve error message for uninferrable types rust-lang#38812 Hello, I tried to improve the error message for uninferrable types. The error code is `E0282`. ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:11 | 2 | let x = vec![]; | - ^^^^^^ cannot infer type for `T` | | | consider giving `x` a type | = note: this error originates in a macro outside of the current crate ``` and ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:15 | 2 | let (x,) = (vec![],); | ---- ^^^^^^ cannot infer type for `T` | | | consider giving a type to pattern | = note: this error originates in a macro outside of the current crate ``` Rust compiler now tries to find uninferred `local`s with type `_` and adds them into the error message. I'm probably wrong on wording that I used. Please feel free to suggest better alternatives. Thanks @nikomatsakis for mentoring 🍺 Any comments/feedback is more than welcome! Thank you
Improve error message for uninferrable types rust-lang#38812 Hello, I tried to improve the error message for uninferrable types. The error code is `E0282`. ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:11 | 2 | let x = vec![]; | - ^^^^^^ cannot infer type for `T` | | | consider giving `x` a type | = note: this error originates in a macro outside of the current crate ``` and ```rust error[E0282]: type annotations needed --> /home/cengizIO/issue38812.rs:2:15 | 2 | let (x,) = (vec![],); | ---- ^^^^^^ cannot infer type for `T` | | | consider giving a type to pattern | = note: this error originates in a macro outside of the current crate ``` Rust compiler now tries to find uninferred `local`s with type `_` and adds them into the error message. I'm probably wrong on wording that I used. Please feel free to suggest better alternatives. Thanks @nikomatsakis for mentoring 🍺 Any comments/feedback is more than welcome! Thank you
I think this can be closed since we landed this with #39361 |
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
fix rust-lang#40294 obligation cause.body_id is not always a NodeExpr Hello! This fixes rust-lang#40294 and moves tests related to rust-lang#38812 to a much more sensible directory. Thanks to @nikomatsakis and @eddyb
Move E0101 and E0102 logic into new E0282 mechanism rust-lang#40013 Hello there! Previously, me and @nikomatsakis worked on error messages of uninferred locals. (rust-lang#38812) This aims to build up on that by moving certain type checks from `writeback`. With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown. They're replaced with customized versions of `E0282`s instead. ```rust error[E0282]: type annotations needed --> test.rs:2:14 | 2 | let x = |_| {}; | ^ consider giving this closure parameter a type error: aborting due to previous error ``` ```rust error[E0282]: type annotations needed --> test.rs:2:9 | 2 | let x = []; | ^ | | | consider giving `x` a type | cannot infer type for `[_; 0]` error: aborting due to previous error ``` - I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO. - I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this. Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests. Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones. Please do comment on messages, layouts and other details. Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
Move E0101 and E0102 logic into new E0282 mechanism rust-lang#40013 Hello there! Previously, me and @nikomatsakis worked on error messages of uninferred locals. (rust-lang#38812) This aims to build up on that by moving certain type checks from `writeback`. With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown. They're replaced with customized versions of `E0282`s instead. ```rust error[E0282]: type annotations needed --> test.rs:2:14 | 2 | let x = |_| {}; | ^ consider giving this closure parameter a type error: aborting due to previous error ``` ```rust error[E0282]: type annotations needed --> test.rs:2:9 | 2 | let x = []; | ^ | | | consider giving `x` a type | cannot infer type for `[_; 0]` error: aborting due to previous error ``` - I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO. - I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this. Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests. Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones. Please do comment on messages, layouts and other details. Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
Move E0101 and E0102 logic into new E0282 mechanism rust-lang#40013 Hello there! Previously, me and @nikomatsakis worked on error messages of uninferred locals. (rust-lang#38812) This aims to build up on that by moving certain type checks from `writeback`. With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown. They're replaced with customized versions of `E0282`s instead. ```rust error[E0282]: type annotations needed --> test.rs:2:14 | 2 | let x = |_| {}; | ^ consider giving this closure parameter a type error: aborting due to previous error ``` ```rust error[E0282]: type annotations needed --> test.rs:2:9 | 2 | let x = []; | ^ | | | consider giving `x` a type | cannot infer type for `[_; 0]` error: aborting due to previous error ``` - I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO. - I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this. Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests. Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones. Please do comment on messages, layouts and other details. Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
Move E0101 and E0102 logic into new E0282 mechanism rust-lang#40013 Hello there! Previously, me and @nikomatsakis worked on error messages of uninferred locals. (rust-lang#38812) This aims to build up on that by moving certain type checks from `writeback`. With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown. They're replaced with customized versions of `E0282`s instead. ```rust error[E0282]: type annotations needed --> test.rs:2:14 | 2 | let x = |_| {}; | ^ consider giving this closure parameter a type error: aborting due to previous error ``` ```rust error[E0282]: type annotations needed --> test.rs:2:9 | 2 | let x = []; | ^ | | | consider giving `x` a type | cannot infer type for `[_; 0]` error: aborting due to previous error ``` - I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO. - I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this. Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests. Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones. Please do comment on messages, layouts and other details. Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
Move E0101 and E0102 logic into new E0282 mechanism #40013 Hello there! ## What's this? Previously, me and @nikomatsakis worked on error messages of uninferred locals. (#38812) This aims to build up on that by moving certain type checks from `writeback`. With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown. They're replaced with customized versions of `E0282`s instead. ## Sample Error Messages #### `E0101` is getting converted into: ```rust error[E0282]: type annotations needed --> test.rs:2:14 | 2 | let x = |_| {}; | ^ consider giving this closure parameter a type error: aborting due to previous error ``` #### `E0102` is getting converted into: ```rust error[E0282]: type annotations needed --> test.rs:2:9 | 2 | let x = []; | ^ | | | consider giving `x` a type | cannot infer type for `[_; 0]` error: aborting due to previous error ``` ## Annoyances - I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO. - I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this. ## Tests Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests. ## Documentation Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones. Please do comment on messages, layouts and other details. ## Appreciation Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
The error message when an unused variable leads to an uninferrable type is confusing:
@nikomatsakis pointed me to #36554. I'm not sure how much that issue was aiming to fix.
If I'm not mistaken, most (all?) of these kinds of situations occur when an expression is flowing into an unannotated local variable binding. It seems like a better error message would highlight the binding as well as the
vec![]
expression (or whatever the uninferrable expression is), and suggest that the variable should either be used elsewhere in the function or annotated with a type./cc @jonathandturner
The text was updated successfully, but these errors were encountered: