use the new "unconstrained type parameter" callbacks more often #40013

nikomatsakis · 2017-02-21T21:03:37Z

#39361 improved our error messages around uninferable types, but there is still room to do better. For one thing, as @arielb1 pointed out, we currently detect these errors in a kind of odd place (when a Sized obligation is not matchable). ~~We could generalize this to any obligation that includes an unresolved inference variable, I suspect.~~ Moreover, there are cases where we don't encounter the error about an unconstrained inference variable until writeback:

fn main() {
    let x = [];
}

Therefore, the error reporting for unknown types in writeback ought to use the new helpers introduced in #39361

cc @cengizio -- would you like to keep on working on this?

UPDATE: I was wrong to say this behavior applies any time we have an unresolved obligation. Sometimes it does, but not always.

The text was updated successfully, but these errors were encountered:

cengiz-io · 2017-02-21T21:15:09Z

Sure! Would love to help!

EDIT: Just started working on this

cengiz-io · 2017-04-17T23:25:21Z

Well that wasn't as easy as I predicted 😝

But I think it's finally done.

Currently waiting for @nikomatsakis's approval

@nikomatsakis

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. 🍻

@nikomatsakis

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. 🍻

@nikomatsakis

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. 🍻

@nikomatsakis

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. 🍻

@nikomatsakis

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. 🍻

nikomatsakis mentioned this issue Feb 21, 2017

error message for uninferrable type #38812

Closed

bors closed this as completed in 6383de1 Apr 19, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

use the new "unconstrained type parameter" callbacks more often #40013

use the new "unconstrained type parameter" callbacks more often #40013

nikomatsakis commented Feb 21, 2017 •

edited

Loading

cengiz-io commented Feb 21, 2017 •

edited

Loading

cengiz-io commented Apr 17, 2017

use the new "unconstrained type parameter" callbacks more often #40013

use the new "unconstrained type parameter" callbacks more often #40013

Comments

nikomatsakis commented Feb 21, 2017 • edited Loading

cengiz-io commented Feb 21, 2017 • edited Loading

cengiz-io commented Apr 17, 2017

nikomatsakis commented Feb 21, 2017 •

edited

Loading

cengiz-io commented Feb 21, 2017 •

edited

Loading