```
error[E0533]: expected value, found struct variant `E::Empty3`
--> $DIR/empty-struct-braces-expr.rs:18:14
|
LL | let e3 = E::Empty3;
| ^^^^^^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | let e3 = E::Empty3 {};
| ++
```
```
error[E0533]: expected value, found struct variant `E::V`
--> $DIR/struct-literal-variant-in-if.rs:10:13
|
LL | if x == E::V { field } {}
| ^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | if x == (E::V { field }) {}
| + +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
--> $DIR/suggestion-highlights.rs:15:5
|
LL | Unit,
| ---- enum variant `Enum::Unit` defined here
...
LL | Enum::Unit();
| ^^^^^^^^^^--
| |
| call expression requires function
|
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
|
LL - Enum::Unit();
LL + Enum::Unit;
|
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
--> $DIR/suggestion-highlights.rs:36:11
|
LL | enum Enum {
| --------- variant or associated item `tuple` not found for this enum
...
LL | Enum::tuple;
| ^^^^^ variant or associated item not found in `Enum`
|
help: there is a variant with a similar name
|
LL | Enum::Tuple(/* i32 */);
| ~~~~~~~~~~~~~~~~;
|
```
More accurate span for type parameter suggestion
After:
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
|
LL | impl Foo<T: Default> for String {}
| ^^^^^^^^^^ associated item constraint not allowed here
|
help: declare the type parameter right after the `impl` keyword
|
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
|
```
Before:
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
|
LL | impl Foo<T: Default> for String {}
| ^^^^^^^^^^ associated item constraint not allowed here
|
help: declare the type parameter right after the `impl` keyword
|
LL | impl<T: Default> Foo<T> for String {}
| ++++++++++++ ~
```
Fix associated item removal suggestion
We were previously telling people to write what was already there, instead of removal (treating it as a `help`). We now properly suggest to remove the code that needs to be removed.
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/E0229.rs:13:25
|
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
| ^^^^^^^ associated item constraint not allowed here
|
help: consider removing this associated item binding
|
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
|
```
After:
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
|
LL | impl Foo<T: Default> for String {}
| ^^^^^^^^^^ associated item constraint not allowed here
|
help: declare the type parameter right after the `impl` keyword
|
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
|
```
Before:
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
|
LL | impl Foo<T: Default> for String {}
| ^^^^^^^^^^ associated item constraint not allowed here
|
help: declare the type parameter right after the `impl` keyword
|
LL | impl<T: Default> Foo<T> for String {}
| ++++++++++++ ~
```
We were previously telling people to write what was already there, instead of removal.
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/E0229.rs:13:25
|
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
| ^^^^^^^ associated item constraint not allowed here
|
help: consider removing this associated item binding
|
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
|
```
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:
- `ConstArgKind` gets a new `Path` variant, and all const params are now
represented using it. Non-param paths still use `ConstArgKind::Anon`
to prevent this change from getting too large, but they will soon use
the `Path` variant too.
- `ConstArg` gets a distinct `hir_id` field and its own variant in
`hir::Node`. This affected many parts of the compiler that expected
the parent of an `AnonConst` to be the containing context (e.g., an
array repeat expression). They have been changed to check the
"grandparent" where necessary.
- Some `ast::AnonConst`s now have their `DefId`s created in
rustc_ast_lowering rather than `DefCollector`. This is because in some
cases they will end up becoming a `ConstArgKind::Path` instead, which
has no `DefId`. We have to solve this in a hacky way where we guess
whether the `AnonConst` could end up as a path const since we can't
know for sure until after name resolution (`N` could refer to a free
const or a nullary struct). If it has no chance as being a const
param, then we create a `DefId` in `DefCollector` -- otherwise we
decide during ast_lowering. This will have to be updated once all path
consts use `ConstArgKind::Path`.
- We explicitly use `ConstArgHasType` for array lengths, rather than
implicitly relying on anon const type feeding -- this is due to the
addition of `ConstArgKind::Path`.
- Some tests have their outputs changed, but the changes are for the
most part minor (including removing duplicate or almost-duplicate
errors). One test now ICEs, but it is for an incomplete, unstable
feature and is now tracked at #127009.
Automatically taint when reporting errors from ItemCtxt
This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.
based on https://github.com/rust-lang/rust/pull/127357
r? `@fmease`
Move trait selection error reporting to its own top-level module
This effectively moves `rustc_trait_selection::traits::error_reporting` to `rustc_trait_selection::error_reporting::traits`. There are only a couple of actual changes to the code, like moving the `pretty_impl_header` fn out of the specialization module for privacy reasons.
This is quite pointless on its own, but having `error_reporting` as a top-level module in `rustc_trait_selection` is very important to make sure we have a meaningful file structure for when we move **type** error reporting (and region error reporting, with which it's incredibly entangled currently) into `rustc_trait_selection`. I've opened a tracking issue here: #127492
r? lcnr
Uplift elaboration into `rustc_type_ir`
Allows us to deduplicate and consolidate elaboration (including these stupid elaboration duplicate fns i added for pretty printing like 3 years ago) so I'm pretty hyped about this change :3
r? lcnr
Make `can_eq` process obligations (almost) everywhere
Move `can_eq` to an extension trait on `InferCtxt` in `rustc_trait_selection`, and change it so that it processes obligations. This should strengthen it to be more accurate in some cases, but is most important for the new trait solver which delays relating aliases to `AliasRelate` goals. Without this, we always basically just return true when passing aliases to `can_eq`, which can lead to weird errors, for example #127149.
I'm not actually certain if we should *have* `can_eq` be called on the good path. In cases where we need `can_eq`, we probably should just be using a regular probe.
Fixes#127149
r? lcnr
