When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
We want the suggested replacement (which IDE tooling and such might offer to
automatically swap in) to, like, actually be correct: suggesting `MyVariant(x)`
when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing, but
Rust is supposed to be the future of computing: we're better than better than
nothing.
As an exceptional case, we excise the prelude path, preferring to suggest
`Some` or `Ok` rather than `std::prelude::v1::Some` and
`std::prelude::v2::Ok`. (It's not worth the effort to future-proof against
hypothetical preludes v2, v3, &c.: we trust our successors to grep—excuse me,
ripgrep—for that.)
Also, don't make this preëmpt the existing probe-for-return-type suggestions,
despite their being looked unfavorably upon, at least in this situation
(https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody
Schafer pointed out that that's a separate issue
(https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229).
This is in the matter of #42764.
`rustc_on_unimplemented` supports referring to trait
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
Fold E0612, E0613 into E0609
As discussed in #42945, with PR 1506 tuple indices are no longer considered a separate case from normal field. This PR folds E06012 ("tuple index out of bounds") and E0613 ("type is not a tuple") into E0609 ("type does not have field with that name")
Resolves#42945
When there're more than one suggestions in the same diagnostic, they are
displayed in their own block, instead of inline. In order to reduce
confusion, those blocks now display the line number.
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
Prior to this PR, when we aborted because a "critical pass" failed, we
displayed the number of errors from that critical pass. While that's the
number of errors that caused compilation to abort in *that place*,
that's not what people really want to know. Instead, always report the
total number of errors, and don't bother to track the number of errors
from the last pass that failed.
This changes the compiler driver API to handle errors more smoothly,
and therefore is a compiler-api-[breaking-change].
Fixes#42793.
Adding diagnostic code 0611 for lifetime errors with one named, one anonymous lifetime parameter
This is a fix for #42517
Note that this only handles the above case for **function declarations** and **traits**.
`impl items` and `closures` will be handled in a later PR.
Example
```
fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
if x > y { x } else { y }
}
```
now displays the following error message. ui tests have been added for the same.
```
error[E0611]: explicit lifetime required in the type of `x`
11 | fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
| ^ consider changing the type of `x` to `&'a i32`
12 | if x > y { x } else { y }
| - lifetime `'a` required
```
#42516
r? @nikomatsakis
Coerce fields to the expected field type
Fully fixes#31260.
This needs a crater run. I was supposed to do this last month but it slipped. Let's get this done.
Detect missing `;` on methods with return type `()`
- Point out the origin of a type requirement when it is the return type
of a method
- Point out possibly missing semicolon when the return type is `()` and
the implicit return makes sense as a statement
- Suggest changing the return type of methods with default return type
- Don't suggest changing the return type on `fn main()`
- Don't suggest changing the return type on impl fn
- Suggest removal of semicolon (instead of being help)
only set "overruled by outer forbid" once for lint groups, by group name
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
(Also, while we're touching context.rs, clean up some unused arguments.)
Resolves#42873.
