Replace parent substs of associated types with inference vars in borrow checker
Fixes https://github.com/rust-lang/rust/issues/83190
Fixes https://github.com/rust-lang/rust/issues/78450
When we normalize an associated type that refers to an opaque type, it can happen that the substs of the associated type do not occur in the projection (they are parent substs). We previously didn't replace those substs with inference vars, which left a concrete region after all regions should have already been replaced with inference vars and triggered a `delay_span_bug`. After we normalize the opaque type, we now try to replace any remaining concrete regions with inference vars.
Handle C-variadic arguments properly when reporting region errors
This pull request fixes#86053. The issue is that for a C-variadic function
```rust
#![feature(c_variadic)]
unsafe extern "C" fn foo(_: (), ...) {}
```
`foo`'s signature will contain only the first parameter (and have `c_variadic` set to `true`), whereas its body has a second argument (a `hir::Pat` for the `...`).
The code for reporting region errors iterates over the body's parameters and tries to fetch the corresponding parameter from the signature; this causes an out-of-bounds ICE for the `...` (though not in the example above, because there are no region errors to report).
I have simply restricted the iteration over the body parameters to exclude `...`, which is fine because `...` cannot cause a region error.
Stop returning a value from `report_assert_as_lint`
This function only ever returns `None`. Make that explicity by not returning a value at all.
`@rustbot` modify labels +C-cleanup +T-compiler
Fix span calculation in format strings
This pull request fixes#86085. The ICE described there is due to an error in the span calculation inside format strings, if the format string is the result of a macro invocation:
```rust
fn main() {
format!(concat!("abc}"));
}
```
currently produces:
```
error: invalid format string: unmatched `}` found
--> test.rs:2:17
|
2 | format!(concat!("abc}"));
| ^ unmatched `}` in format string
```
which is obviously incorrect. This happens because the span of the entire `concat!()` is combined with the _relative_ location of the unmatched `` `}` `` in the _result_ of the macro invocation (i.e. 4).
In #86085, this has led to a span that starts or ends in the middle of a multibyte character, but the root cause was the same. This pull request fixes the problem.
Box `thir::ExprKind::Adt` for performance
`Adt` is the biggest variant in the enum and probably isn't used very often compared to the other expr kinds, so boxing it should be beneficial for performance. We need a perf test to be sure.
Refactor vtable codegen
This refactor the codegen of vtables of miri interpreter, llvm, cranelift codegen backends.
This is preparation for the implementation of trait upcasting feature. cc #65991
Note that aside from code reorganization, there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots, and now the first method is with index 3.
cc `@RalfJung` `@bjorn3`
Improve CTFE UB validation error messages
As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix.
From:
`type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0`
To:
`type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
Fix force-warns to allow dashes.
The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores. This changes it to allow dashes to match the behavior of the A/W/D/F flags.
Fix ICEs on invalid vtable size/alignment const UB errors
The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that.
Fixes#86193
r? `@RalfJung`
(It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
Do not suggest to add type annotations for unnameable types
Consider this example:
```rust
const A = || 42;
struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
--> src/lib.rs:1:7
|
1 | const A = || 42;
| ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/lib.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^
| |
| not allowed in type signatures
| help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`
error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
--> test.rs:1:7
|
1 | const A = || 42;
| ^
|
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
--> test.rs:1:11
|
1 | const A = || 42;
| ^^^^^
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> test.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^ not allowed in type signatures
|
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
--> test.rs:4:14
|
4 | const B: _ = S { t: || 42 };
| ^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
```
Hash DefId in rustc_span.
This is mostly just moving code around. Changes are simplifications of unneeded callbacks from rustc_span to rustc_middle.
r? `@petrochenkov`
Make `relate_type_and_mut` public
#85343 improved diagnostics around `Relate` impls but made `relate_type_and_mut` private, which was accessible as `relate` previously. This makes it public so that we can use it on rust-semverver.
r? ```@Aaron1011```
Detect incorrect vtable alignment during const eval
This PR fixes#86132 by detecting invalid alignment values for trait objects in the interpreter, and emitting an error about this conversion failure, to avoid the ICE.
I've noticed that the error emitted at a50d72158e/compiler/rustc_mir/src/interpret/traits.rs (L163-L166) doesn't seem to be present in the const-ub tests, so I've tried adding a test that triggers both of these cases: one for the invalid size, and another for the invalid alignment that #86132 tracks (I have found different magic values triggering different `Align::from_bytes` errors than the "power of 2" one, if need be).
However, when doing that, I *cannot* for the life of me figure out the correct incantation to make these 2 errors trigger with the "it is undefined behavior to use this value" message rather than the "any use of this value will cause an error" lint.
I've tried Oli's suggestions of different values, tuples and arrays, using the transparent wrapper trick from the other tests and I was only able to trigger the regular const-ub errors about the size of the vtable, or that the drop pointer was invalid. Maybe these "type validation failed" errors happen before this part of the interpreter is reached and there just needs some magic incorrect values to bypass them, I don't know.
Since this fixes an ICE, and if the constants are indeed used, these 2 tests will turn into a hard error, I thought I'd open the PR anyways. And if ```@RalfJung``` you know of a way I could manage that (if you think that these tests are worth checking that the `throw_ub_format!` does indeed create const-ub errors as we expect) I'd be grateful.
For that reason, r? ```@RalfJung``` and cc ```@oli-obk.```
Do not suggest ampmut if rhs is already mutable
Removes invalid suggestion in #85765, although it should highlight the user type instead of the local variable.
Looking at the comments of this line:
84b1005bfd/compiler/rustc_mir_build/src/build/matches/mod.rs (L2107)
It was intentionally set to `None`, causing it to highlight the local variable instead. I am not sure if I will be able to fix it.
Fixes#85765
Fix some diagnostic issues with const_generics_defaults feature gate
This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
Don't use a generator for BoxedResolver
The generator is non-trivial and requires unsafe code anyway. Using regular unsafe code without a generator is much easier to follow.
Based on #85810 as it touches rustc_interface too.
Suggest a trailing comma if a 1-tuple is expected and a parenthesized expression is found
This pull request fixes#86100. The following code:
```rust
fn main() {
let t: (i32,) = (1);
}
```
currently produces:
```
warning: unnecessary parentheses around assigned value
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ^^^ help: remove these parentheses
|
= note: `#[warn(unused_parens)]` on by default
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
error: aborting due to previous error; 1 warning emitted
```
With my changes, I get the same warning and the following error:
```
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
help: use a trailing comma to create a tuple with one element
|
2 | let t: (i32,) = (1,);
| ^^^^
```
i.e. I have added a suggestion to add a trailing comma to create a 1-tuple. This suggestion is only issued if a 1-tuple is expected and the expression (`(1)` in the example above) is surrounded by parentheses and does not already have a tuple type. In this situation, I'd say that it is pretty likely that the user meant to create a tuple.
