We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`.
This slightly worsens the span of `infer_var.method()` which is now the
same as for `Box::new(infer_var).method()`.
Unlike `structurally_resolve_type`, `probe_op` does not check whether
the infcx is already tainted, so this results in 2 previously not emitted
errors.
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#2 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#1 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
No source fixes
This PR started as a fix for a rendering bug that [got noticed in #143661](https://github.com/rust-lang/rust/pull/143661#discussion_r2199109530), but turned into a fix for any rendering bugs related to files with no source.
- Don't add an end column separator after a file with no source
- Add column separator before secondary messages with no source
- Render continuation between no source labels
Before
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
╰╴
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
╰ note: private field
│
╰ note: private field
```
After
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╰╴
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
├ note: private field
│
╰ note: private field
```
Note: This PR also makes it so `rustc` and `annotate-snippets` match in these cases
ci: Begin running ui tests with `rust.debuginfo-level-tests=1`
To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests work with different debuginfo levels. See https://github.com/rust-lang/rust/issues/61117.
When I looked at run time for different CI jobs, **x86_64-gnu-debug** was far from the bottleneck, so it should be fine to make it perform more work.
A handful of tests are failing so we need to force debuginfo=0 on those for now.
We'll start small with debuginfo=1. We'll step up to debuginfo=2 once most (all?) tests can handle debuginfo=1. There are more failures with debuginfo=2 than with debuginfo=1.
On E0277, point at type that doesn't implement bound
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
To reduce risk of regressing on generating debuginfo e.g. in the form of
ICE:s. This will also ensure that future ui tests support different
debuginfo levels.
When I looked at run time for different CI jobs, **x86_64-gnu-debug**
was far from the bottle neck, so it should be fine to make it perform
more work.
Rehome 37 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
rework GAT borrowck limitation error
The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization.
This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in https://github.com/rust-lang/rust/pull/140737#discussion_r2259592651.
r? types cc ```@amandasystems```
Modify `AttributeTemplate` to support list of alternatives for list and name value attribute styles.
Suggestions now provide more correct suggested code:
```
error[E0805]: malformed `used` attribute input
--> $DIR/used_with_multi_args.rs:3:1
|
LL | #[used(compiler, linker)]
| ^^^^^^------------------^
| |
| expected a single argument here
|
help: try changing it to one of the following valid forms of the attribute
|
LL - #[used(compiler, linker)]
LL + #[used(compiler)]
|
LL - #[used(compiler, linker)]
LL + #[used(linker)]
|
LL - #[used(compiler, linker)]
LL + #[used]
|
```
instead of the prior "masking" of the lack of this feature by suggesting pipe-separated lists:
```
error[E0805]: malformed `used` attribute input
--> $DIR/used_with_multi_args.rs:3:1
|
LL | #[used(compiler, linker)]
| ^^^^^^------------------^
| |
| expected a single argument here
|
help: try changing it to one of the following valid forms of the attribute
|
LL - #[used(compiler, linker)]
LL + #[used(compiler|linker)]
|
LL - #[used(compiler, linker)]
LL + #[used]
|
```
Point at the `Fn()` or `FnMut()` bound that coerced a closure, which caused a move error
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
Fixrust-lang/rust#68119, by pointing at `Fn` and `FnMut` bounds involved in move errors.
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error.
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:15:25
|
14 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
15 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
16 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
|
help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once
--> f111.rs:12:53
|
12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {}
| ^^^^^^^^^
help: consider cloning the value if the performance cost is acceptable
|
16 | if foo.clone().map_or(false, |f| f.foo()) {
| ++++++++
```
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
Add support for `ty::Instance` path shortening in diagnostics
Make `ty::Instance` able to use `short_string` and usable in structured errors directly. Remove some ad-hoc type shortening logic.
`tests/ui/issues/`: The Issues Strike Back [3/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ```@jieyouxu```
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
When we don't actually print out a shortened type we don't need the "use `--verbose`" note.
On E0599 show type identity to avoid expanding the receiver's generic parameters.
Unify wording on `long_ty_path` everywhere.
Print thread ID in panic message
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: dist-apple-various
try-job: dist-various-*
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: dist-x86_64-solaris
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-mingw-1
try-job: x86_64-msvc-1
bors