When the obligation that couldn't be fulfilled is specific to a nested
obligation, maintain both the nested and parent obligations around for
more accurate and detailed error reporting.
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
This doesn't mention that using an existing lifetime is possible, but
that would hopefully be clear as always being an option. The intention
of this is to teach newcomers what the lifetime syntax is.
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
Remove blanket check for existence of other errors before emitting
"type annotation needed" errors, and add some eager checks to avoid
adding obligations when they refer to types that reference
`[type error]` in order to reduce unneded errors.
```
error[E0282]: type annotations needed in `std::result::Result<i32, E>`
--> file7.rs:3:13
|
3 | let b = Ok(4);
| - ^^ cannot infer type for `E` in `std::result::Result<i32, E>`
| |
| consider giving `b` a type`
```
When encountering code where type inference fails, add more actionable
information:
```
fn main() {
let foo = Vec::new();
}
```
```
error[E0282]: type annotations needed for `std::vec::Vec<_>`
--> $DIR/vector-no-ann.rs:2:16
|
LL | let foo = Vec::new();
| --- ^^^^^^^^ cannot infer type for `T`
| |
| consider giving `foo` the type `std::vec::Vec<_>` with the type parameter `T` specified
```
We still need to modify type printing to optionally accept a
`TypeVariableTable` in order to properly print `std::vec::Vec<T>`.
CC #25633.
