Move tests in the statics category
I have moved some tests I feel belong in the statics directory. Please review and let me know if this is the correct way. I think on the first two files I moved, i forgot to turn off rust analyzer and it probably formatted the files, will this be an issue?
* Move issue-50411 to tests/ui/mir/inliner-double-elaborate
* Addded the link for the issue to inliner-double-elaborate.rs
* Fix tidy issues
* Renamed to inliner-double-elaborate.rs
ui/lto: move and rename two tests from issues/
Move:
- `tests/ui/issues/issue-44056.rs` -> `tests/ui/lto/lto-avx-target-feature.rs`
- The first test enables both AVX target features and LTO but does not exercise AVX-specific behavior. The test primarily checks that LTO builds successfully with these flags; place it under `ui/lto` for consistency.
- `tests/ui/issues/issue-51947.rs` -> `tests/ui/lto/lto-weak-merge-functions.rs`
- The second test exercises weak linkage interacting with LTO (merge-functions), so it should belong in `ui/lto`.
I have also added a commented line at the top of each test file indicating the issue it originated from.
Point turbofish inference errors at the uninferred generic arg
Follow-up to rust-lang/rust#153751.
When a method call has a turbofish with an uninferred generic argument, point the diagnostic span at the specific `_` that couldn't be inferred instead of the method name.
Before:
```rust
LL | S.f::<u32, _>(42);
| ^ cannot infer type of the type parameter `B`
```
After:
```rust
LL | S.f::<u32, _>(42);
| ^ cannot infer type of the type parameter `B`
```
Path expressions (`None::<_>`, `foo::<_>()`) are not handled yet, that's a separate code path.
cc @eggyal
Tweak E0599 note
When not finding a method for a type, but finding it for a single other impl, special case the output to emit a single message instead of a list.
```
error[E0599]: no associated item named `C` found for struct `Fail<i32, u32>` in the current scope
--> $DIR/wrong-projection-self-ty-invalid-bivariant-arg2.rs:15:23
|
LL | struct Fail<T: Proj<Assoc = U>, U>(T);
| ---------------------------------- associated item `C` not found for this struct
...
LL | Fail::<i32, u32>::C
| ^ associated item not found in `Fail<i32, u32>`
|
= note: the associated item was found for `Fail<i32, i32>`
```
instead of
```
= note: the associated item was found for
- `Fail<i32, i32>`
```
Point at unit structs on foreign crates in type errors when they are the pattern of a binding
Consts and unit structs in patterns can be confusing if they are mistaken for new bindings. We already provide some context for unit structs and consts that come from the current crate, we now also point at those from foreign crates, and we properly skip cases where the pattern has type parameters which can't be confused with a new binding. So not suggest making a new binding when other suggestions are already emitted, as the likelihood of the other suggestions being what the user intended is higher. Make new binding suggestion verbose.
Fixrust-lang/rust#129792.
```
error[E0308]: mismatched types
--> fi.rs:8:9
|
1 | struct percentage;
| ----------------- unit struct defined here
...
8 | let percentage = 4i32;
| ^^^^^^^^^^ ---- this expression has type `i32`
| |
| expected `i32`, found `percentage`
| `percentage` is interpreted as a unit struct, not a new binding
help: introduce a new binding instead
|
8 - let percentage = 4i32;
8 + let other_percentage = 4i32;
|
```
remove several redundant tests
Remove the following tests:
* `binding/match-naked-record.rs`: duplicate of `binding/match-naked-record-expr.rs`
* `issues/issue-5192.rs`: duplicate of `box/unit/unique-object-move.rs`
* `macros/unreachable.rs`: duplicate of `macros/unreachable-macro-panic.rs`
* `issues/issue-4830.rs`: this used to test that a parsing error was emitted for obsolete `~` syntax, this was removed long ago
* `moves/array-copy-move.rs`: this used to test that calling methods on a vec with type error elements did not ICE. It no longer makes sense since it contains no method call and the integers do not cause type errors anymore.
Consts and unit structs in patterns can be confusing if they are mistaken for new bindings. We already provide some context for unit structs and consts that come from the current crate, we now also point at those from foreign crates, and we properly skip cases where the pattern has type parameters which can't be confused with a new binding. Make new binding suggestion verbose.
- On `const` and `static` point at the type (like we do for let bindings)
- On fn calls, point at const parameter in fn definition
- On type, point at const parameter in type definition
- On array type lengths, explain that array length is always `usize`
- On enum variant discriminant, mention `repr`
When not finding a method for a type, but finding it for a single other impl, special case the output to emit a single message instead of a list.
```
error[E0599]: no associated item named `C` found for struct `Fail<i32, u32>` in the current scope
--> $DIR/wrong-projection-self-ty-invalid-bivariant-arg2.rs:15:23
|
LL | struct Fail<T: Proj<Assoc = U>, U>(T);
| ---------------------------------- associated item `C` not found for this struct
...
LL | Fail::<i32, u32>::C
| ^ associated item not found in `Fail<i32, u32>`
|
= note: the associated item was found for `Fail<i32, i32>`
```
instead of
```
= note: the associated item was found for
- `Fail<i32, i32>`
```
Migrate 11 tests from tests/ui/issues to specific directories
Moved 11 regression tests from `tests/ui/issues` to their relevant subdirectories (`imports`, `pattern`, `lint`, and `typeck`).
* Added standard issue tracking comments at the top of each file.
* Relocated associated `aux-build` files.
* Ran `./x.py test --bless` successfully.
Perform many const checks in typeck
Some smaller diagnostic changes, the biggest ones avoided by https://github.com/rust-lang/rust/pull/148641
We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended).
r? @fee1-dead
Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of https://github.com/rust-lang/rust/pull/126810 and https://github.com/rust-lang/rust/pull/128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Provide more context on trait bounds being unmet due to imperfect derive
When encountering a value that has a borrow checker error where the type was previously moved, when suggesting cloning verify that it is not already being derived. If it is, explain why the `derive(Clone)` doesn't apply:
```
note: if `TypedAddress<T>` implemented `Clone`, you could clone the value
--> $DIR/derive-clone-implicit-bound.rs:6:1
|
LL | #[derive(Clone, Copy)]
| ----- derived `Clone` adds implicit bounds on type parameters
LL | pub struct TypedAddress<T>{
| ^^^^^^^^^^^^^^^^^^^^^^^^-^
| | |
| | introduces an implicit `T: Clone` bound
| consider manually implementing `Clone` for this type
...
LL | let old = self.return_value(offset);
| ------ you could clone this value
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
note: required for `Id<SomeNode>` to implement `PartialEq`
--> $DIR/derive-implicit-bound.rs:5:10
|
LL | #[derive(PartialEq, Eq)]
| ^^^^^^^^^
LL | pub struct Id<T>(PhantomData<T>);
| - unsatisfied trait bound introduced in this `derive` macro
= help: consider manually implementing `PartialEq` to avoid undesired bounds
```
Mention that the trait could be manually implemented in E0599.
Fixrust-lang/rust#108894. Address rust-lang/rust#143714. Address #rust-lang/rust#146515 (but ideally would also suggest constraining the fn bound correctly as well).
mGCA: Make trait object types with type-level associated consts dyn compatible
Under feature `min_generic_const_args` (mGCA) (rust-lang/rust#132980), render traits with non-parametrized type-level associated constants (i.e., `#[type_const]` ones) dyn compatible but force the user to specify all type-level associated consts in the trait object type via bindings (either directly, via supertrait bounds and/or behind trait aliases) just like associated types, their sibling.
Fixesrust-lang/rust#130300 (feature request).
Fixesrust-lang/rust#136063 (bug).
Fixesrust-lang/rust#137260 (bug).
Fixesrust-lang/rust#137514 (bug).
While I'm accounting for most illegal `Self` references via const projections & params, I'm intentionally ignoring RUST-123140 (and duplicates) in this PR which is to be tackled some other time.
Additional context: Crate `rustc-demangle` had to be updated to fix v0 demangling. I've patched it in PR https://github.com/rust-lang/rustc-demangle/pull/87 which was was released in version 0.1.27 via PR https://github.com/rust-lang/rustc-demangle/pull/88.
Jonathan Brouwer