Move tests from `tests/ui/issues/` to appropriate directories
In this PR, I am moving the following test from `tests/ui/issues` directory to the appropriate directories, followed by the addition of issue links at the top and reblessing of the stderr files:
| old-name | new-sub-dir | new-name |
|-|-|-|
| `issue-29516.rs` | `auto-traits/` | `distinct-type-tuple-by-negative-impl.rs` |
| `issue-3874.rs` | `binding/` | `ref-in-let-lhs-in-field.rs` |
| `issue-32782.rs` | `feature-gates/` | `feature-gate-check-nested-macro-invocation.rs` |
| `issue-32782.stderr` | `feature-gates/` | `feature-gate-check-nested-macro-invocation.stderr` |
| `issue-5100.rs` | `pattern/` | `match-errors-derived-error-suppression.rs` |
| `issue-5100.stderr` | `pattern/` | `match-errors-derived-error-suppression.stderr` |
| `issue-21033.rs` | `pattern/` | `match-struct-var-having-boxed-field.rs` |
r? Kivooeo
r? Teapot4195
UI automation
# To move issue-3154 and issue-16774 to functional subdirectories:
I have moved 2 tests from tests/ui/issues to their appropriate directories using "test-manager" tool.
## Changes:
- Moved tests/ui/issues/issue-3154.rs to tests/ui/borrowck/missing-lifetime-in-return.rs
- Moved tests/ui/issues/issue-16774.rs to tests/ui/deref/derefmut-closure-drop-order.rs
These moves where performed using the test-manager automation tool.
move borrow checker tests
Hi, I have moved some tests I think should be in the borrowck category. Please let me know if there are issues. r? @Kivooeo
Related to rust-lang/rust#133895
Migrate some tests from `tests/ui/issues` to appropriate directories
The following changes have been made in the pull request:
- `tests/ui/issues/issue-25746-bool-transmute.rs` ➝ `tests/ui/transmute/transmute-bool-u8.rs`
- `tests/ui/issues/issue-32377.{rs,stderr}` ➝ `tests/ui/intrinsics/transmute-phantomdata-generic-unequal-size.{rs,stderr}`
The issue links have also been added at the top of each `.rs` file.
r? Kivooeo
Migrate transmute tests
I have made the following changes in this PR:
- `tests/ui/issues/issue-23477.rs` ➝ `tests/ui/transmute/transmute-slice-to-dst.rs`
- `tests/ui/issues/issue-28625.{rs,stderr}` ➝ `tests/ui/transmute/transmute-associated-type-to-slice.{rs,stderr}`
The reason I changed the trait name from `trait Bar` to `trait MyTrait` and `type Bar` to `type MyType` is that the same name (i.e., `Bar`) for the trait and associated type was making it harder to follow the test. It was confusing for me, at least.
r? Kivooeo
Migrate UI tests
In this pull request, I am migrating the following files and adding a comment at the top, including a link to the issue they were regression tests for:
- `tests/ui/issues/issue-4735.rs` ➝ `tests/ui/drop/drop-noncopyable-raw-pointer.rs`
- `tests/ui/issues/issue-17734.rs` ➝ `tests/ui/codegen/box-str-drop-glue.rs`
r? Kivooeo
Move ui/issues tests to relevant subdirectories
Related to https://github.com/rust-lang/rust/issues/133895 and [Reorganisation of tests/ui/issues for GSOC](https://github.com/rust-lang/google-summer-of-code?tab=readme-ov-file#reorganisation-of-testsuiissues)
This is the first PR in a batch of PRs.
Moves `ui/issues/issue-17546.rs` -> `ui/variants/variant-result-noresult-used-as-type.rs`
Approach:
1. Check linked issue and test contents, determine new target directory
2. Move / rename tests to reflect purpose.
3. Add issue link / comments in separate commit.
4. Rebless if necessary and remove obsolete stderr.
r? @Kivooeo
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
Jonathan Brouwer