Tweak wording of failed predicate in inference error
Special case message talking about `Predicate` that couldn't be satisfied when in inference errors so that we don't say "cannot satisfy `_: Trait`" and instead say "type must implement `Trait`".
Fix non-module `parent_module` in stripped cfg diagnostics
Fixesrust-lang/rust#153848
Old `parent_module` is from the `parent_node` in `append_stripped_cfg_item`, it cannot be assumed that it points to a real module. So call `expect_module` on it will cause ICE.
The first commit rename `parent_module` to `parent_scope`, and the second using `get_nearest_non_block_module` to find the nearest `module` of `parent_scope` in `find_cfg_stripped`, which should be the correct `parent_module`.
Add the option to run UI tests with the parallel frontend
This PR adds two arguments for tests:
1. `--parallel-frontend-threads`: specify `-Zthread` to compile test case (currently UI tests only)
2. `--iteration-count`: the number of times to run each test
Also, due to the non-deterministic diagnostic orders and cycle errors, this PR adds the directive `//@ ignore-parallel-frontend` to ignore tests with cycle error when the parallel-frontend is enabled (by `--parallel-frontend-threads`) and enables `//@ compare-output-by-lines` by default.
Context: [#t-compiler/parallel-rustc > Add the parallel front-end test suite @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Add.20the.20parallel.20front-end.20test.20suite/near/578781369)
This PR should work with https://github.com/rust-lang/rust/pull/153797 together.
Suppress self-referential associated type constraint suggestion
Fixesrust-lang/rust#112104
When comparing `Option<&I::Item>` against `Option<I::Item>`, the compiler decomposes the mismatch into `expected = &<I as Iterator>::Item` vs `found = <I as Iterator>::Item`. ARM 2 in `note_and_explain_type_err` matches because `found` is a projection, and would suggest `Item = &<I as Iterator>::Item` — constraining the associated type to something that contains itself.
ARM 1 (`expected_projection`) already guards against this with `found.contains(expected)`. ARM 2 was missing the symmetric check. This adds `expected.contains(found)` to the match guard.
Before:
```rust
help: consider constraining the associated type `<I as Iterator>::Item` to `&<I as Iterator>::Item`
|
1 | fn foo<I: Iterator<Item = &<I as Iterator>::Item>>(iter: &mut I) {
| +++++++++++++++++++++++++++++++
```
After: bogus suggestion is gone, and the existing `.as_ref()` suggestion from `hir_typeck` still fires correctly.
r? @estebank
Remove redundant fields from `QueryStackFrame`
- Follow-up to https://github.com/rust-lang/rust/pull/153867#discussion_r2935993621
---
Now that QueryStackFrame holds a TaggedQueryKey, it turns out that all of its other fields are redundant and can be removed:
- An explicit dep-kind is redundant here. If we want to find the query name, or check for specific queries, we can inspect the `TaggedQueryKey` instead.
- Similarly, in cases where the key is some kind of `DepId`, we can extract it directly from the `TaggedQueryKey`.
r? nnethercote
Don't look for non-type-level assoc consts when checking trait object types
On main, when looking for assoc items that weren't specified in a given trait object type (via binding), we comb through all (eligible) assoc consts whether type-level or not even though you're not allowed to bind non-type-level assoc consts.
That's usually fine because traits containing (eligible) non-type-level assoc consts are dyn incompatible, so the trait object type is ~already considered ill-formed. Therefore, in PR rust-lang/rust#150843, I saved myself the extra effort, esp. since back then it was more annoying to check if the const item was declared type-level.
<sub>(More concretely: In bodies, we check for all dyn compatibility violations when lowering the trait object type, so we will bail out early with an error; in contrast, item signatures / non-bodies get wfchecked (`WellFormed` obligation) after lowering which includes dyn compatiblity checking (`DynCompatible` obligation); however to reduce the amount of diags, during lowering if there are any unspecified assoc items, we'll check them for dyn compatibility and bail out early if any of them tests negative.)</sub>
Now, we obviously don't wfcheck the defsite of (eager) type aliases which breaks the assumption that such trait object types get rejected. This led to the regression found in rust-lang/rust#153731: The ill-formed trait object type doesn't get rejected (as is expected) but we now require the single (non-type-level) assoc const to be bound in the dyn-Trait which we didn't do before. The actual error talks about dyn incompatibility due to the aforementioned extra check that's usually there to contain the number of diags.
Fixes [after beta backport] rust-lang/rust#153731.
suggest valid features when target feature is invalid
I run into this quite frequently, where I remember some part of a feature name but not the exact name. Now this emits suggestions like
```
error: the feature named `+avx512` is not valid for this target
--> $DIR/invalid-attribute.rs:127:18
|
LL | #[target_feature(enable = "+avx512")]
| ^^^^^^^^^^^^^^^^^^ `+avx512` is not valid for this target
|
= help: valid names are: `avx512f`, `avx2`, `avx512bw`, `avx512cd`, and `avx512dq` and 74 more
```
Add `From` impls for wrapper types
- ~`From<T: Copy> for ManuallyDrop<T>`~
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
- `From<T> for ThinBox<T>` (unstable)
- `From<T> for UniqueRc<T>` (unstable)
- `From<T> for UniqueArc<T>` (unstable)
@rustbot label T-libs-api needs-fcp
Also needs a crater run, as the insta-stable impls are technically breaking changes.
Special case message talking about `Predicate` that couldn't be satisfied when in inference errors so that we don't say "cannot satisfy `_: Trait`" and instead say "type must implement `Trait`".
Gate `ConstParamTy_` trait behind `const_param_ty_trait` feature
Initially even when user wasn't using unsized const params, the only way to implement/name `ConstParamTy_` was to use `#![feature(unsized_const_params]`, now its gated under `const_param_ty_trait` feature, implied by `unsized_const_params`.
I've also changed use of `unsized_const_params` in tests which were using it only to implement `ConstParamTy_` without using unsized
r? BoxyUwU
An explicit dep-kind is redundant here. If we want to find the query name, or
check for specific queries, we can inspect the `TaggedQueryKey` instead.
Similarly, in cases where the key is some kind of `DefId`, we can extract it
directly from the `TaggedQueryKey`.
Re-export `rustc_middle::query::{QuerySystem, QueryVTable}`
- Follow-up to https://github.com/rust-lang/rust/pull/153760#discussion_r2928848418.
---
All of the other public items in `rustc_middle::query::plumbing` are re-exported from `query`, except for these two, for no particular reason that I can see.
Re-exporting them allows `rustc_middle::query::plumbing` to have its visibility reduced to pub(crate).
Imports within `rustc_middle` have also been updated to consistently use the re-exports in `crate::query`.
r? nnethercote
Rename all-query functions.
There are four functions that use `for_each_query_vtable!` to call an "inner" function. They are:
- `collect_active_jobs_from_all_queries` -> `gather_active_jobs`
- `alloc_self_profile_query_strings` -> `alloc_self_profile_query_strings_for_query_cache`
- `encode_all_query_results` -> `encode_query_results`
- `query_key_hash_verify_all` -> `query_key_hash_verify`
These names are all over the place. This commit renames them as follows:
- `collect_active_query_jobs{,_inner}`
- `alloc_self_profile_query_strings{,_inner}`
- `encode_query_values{,_inner}`
- `verify_query_key_hashes{,_inner}`
This:
- puts the verb at the start
- uses `_inner` for all the inners (which makes sense now that the inners are all next to their callers)
- uses `_query_` consistently
- avoids `all`, because the plurals are enough
- uses `values` instead of `results`
- removes the `collect`/`gather` distinction, which is no longer important
r? @Zalathar
All of the other public items in `rustc_middle::query::plumbing` are
re-exported from `query`, except for these two, for no particular reason that I
can see.
Re-exporting them allows `rustc_middle::query::plumbing` to have its visibility
reduced to pub(crate).
Imports within `rustc_middle` have also been updated to consistently use the
re-exports in `crate::query`.
There are four functions that use `for_each_query_vtable!` to call an "inner"
function. They are:
- collect_active_jobs_from_all_queries -> gather_active_jobs
- alloc_self_profile_query_strings -> alloc_self_profile_query_strings_for_query_cache
- encode_all_query_results -> encode_query_results
- query_key_hash_verify_all -> query_key_hash_verify
These names are all over the place. This commit renames them as follows:
- collect_active_query_jobs{,_inner}
- alloc_self_profile_query_strings{,_inner}
- encode_query_values{,_inner}
- verify_query_key_hashes{,_inner}
This:
- puts the verb at the start
- uses "inner" for all the inners (which makes sense now that the inners are
all next to their callers)
- uses `_query_` consistently
- avoids `all`, because the plurals are enough
- uses `values` instead of `results`
- removes the `collect`/`gather` distinction, which is no longer
important
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#153639 (Remove `QueryInfo`.)
- rust-lang/rust#153570 (MaybeUninit: mention common mistakes in assume_init docs; link to validity invariant docs)
- rust-lang/rust#153724 (Show named lifetime in closure upvar diagnostics)
- rust-lang/rust#153793 (Add overview documentation for `std::mem`.)
- rust-lang/rust#153922 (rustc_mir_build only depends on rustc_lint_defs, not rustc_lint)
- rust-lang/rust#153923 (run_make_support: Print the command and output even if it succeeds)
- rust-lang/rust#153925 (Provide better suggestions for inference errors on `.collect()?`)
- rust-lang/rust#153928 (remove several redundant tests)
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.
Provide better suggestions for inference errors on `.collect()?`
When encountering an inference error when calling `.collect()` followed by `?`, detect the return type of the enclosing function and suggest `.collect::<Result<_, _>>()?` instead of `.collect::<Vec<_>>()?`:
```
error[E0283]: type annotations needed
--> $DIR/question-mark-type-infer.rs:10:21
|
LL | l.iter().map(f).collect()?
| ^^^^^^^ cannot infer type of the type parameter `B` declared on the method `collect`
|
= note: cannot satisfy `_: FromIterator<Result<i32, ()>>`
note: required by a bound in `collect`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider specifying the generic argument
|
LL | l.iter().map(f).collect::<Result<_, _>>()?
| ++++++++++++++++
```
On inference error in let binding, account for `?`:
```
error[E0282]: type annotations needed
--> $DIR/question-mark-type-inference-in-chain.rs:31:9
|
LL | let mut tags = lines.iter().map(|e| parse(e)).collect()?;
| ^^^^^^^^
...
LL | tags.sort();
| ---- type must be known at this point
|
help: consider giving `tags` an explicit type
|
LL | let mut tags: Vec<_> = lines.iter().map(|e| parse(e)).collect()?;
| ++++++++
```
Address rust-lang/rust#129269.
run_make_support: Print the command and output even if it succeeds
Previously, it was quite hard to get access to this output because it was printed to a buffer in memory and then discarded. This output is already hidden behind libtest's output capturing, we don't need to hide it twice.
Add overview documentation for `std::mem`.
I heard that `std::mem` sounds scary to some people, and how it’s described — “Basic functions for dealing with memory” — sounds even to me like something that should be avoided, not even because it would be unsafe, but because it is too low-level.
Let’s fix that by telling people about what they can actually find in the module, without having to read all the individual item descriptions.
The exact contents of the list are, of course, highly debatable, and I chose not to include any of the unstable or deprecated items, nor to include `Discriminant` as well as `discriminant`. I’m also not particularly happy with the wording of the introductory paragraph.
Show named lifetime in closure upvar diagnostics
Fixesrust-lang/rust#153545.
When a closure captures a variable whose type involves a named lifetime from the parent function (e.g., `'a`), the borrow checker's region renumbering creates a separate `RegionVid` for each occurrence of the erased lifetime in the closure's upvar type. These new `RegionVid`s have no `external_name`, so diagnostics fall back to synthetic names like `'1`.
This PR recovers the original lifetime name by matching the closure's upvar type against the parent function's parameter type (obtained via `liberate_late_bound_regions`). Both types have the same structure but different region representations, the parent has `ReLateParam`/`ReEarlyParam` with real names, the closure has `ReVar` from renumbering. Walking them in parallel with `for_each_free_region` lets us find which named lifetime corresponds to the anonymous `RegionVid`.
Before:
```rust
error[E0716]: temporary value dropped while borrowed
--> test.rs:11:21
|
6 | fn apply<'a>(
| -- lifetime `'1` defined here
```
After:
```rust
error[E0716]: temporary value dropped while borrowed
--> test.rs:11:21
|
6 | fn apply<'a>(
| -- lifetime `'a` defined here
```
The fix gracefully falls back to the existing `'1` naming when it can't match, nested closures, local variables (not parameters), destructuring patterns, or partial captures where the type structures diverge.
Remove `QueryInfo`.
`CycleError` has one field containing a `(Span, QueryStackFrame<I>)` and another field containing a `QueryInfo`, which is a struct containing just a `Span` and a `QueryStackFrame<I>`.
We already have the `Spanned` type for adding a span to something. This commit uses it for both fields in `CycleError`, removing the need for `QueryInfo`. Which is good for the following reasons.
- Any type with `Info` in the name is suspect, IMO.
- `QueryInfo` can no longer be confused with the similar `QueryJobInfo`.
- The doc comment on `QueryInfo` was wrong; it didn't contain a query key.
r? @Mark-Simulacrum
`CycleError` has one field containing a `(Span, QueryStackFrame<I>)` and
another field containing a `QueryInfo`, which is a struct containing
just a `Span` and a `QueryStackFrame<I>`.
We already have the `Spanned` type for adding a span to something. This
commit uses it for both fields in `CycleError`, removing the need for
`QueryInfo`. Which is good for the following reasons.
- Any type with `Info` in the name is suspect, IMO.
- `QueryInfo` can no longer be confused with the similar `QueryJobInfo`.
- The doc comment on `QueryInfo` was wrong; it didn't contain a query
key.
When encountering an inference error when calling `.collect()` followed by `?`, detect the return type of the enclosing function and suggest `.collect::<Result<_, _>>()?` instead of `.collect::<Vec<_>>()?`:
```
error[E0283]: type annotations needed
--> $DIR/question-mark-type-infer.rs:10:21
|
LL | l.iter().map(f).collect()?
| ^^^^^^^ cannot infer type of the type parameter `B` declared on the method `collect`
|
= note: cannot satisfy `_: FromIterator<Result<i32, ()>>`
note: required by a bound in `collect`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider specifying the generic argument
|
LL | l.iter().map(f).collect::<Result<_, _>>()?
| ++++++++++++++++
```
On inference error in let binding, account for `?`:
```
error[E0282]: type annotations needed
--> $DIR/question-mark-type-inference-in-chain.rs:31:9
|
LL | let mut tags = lines.iter().map(|e| parse(e)).collect()?;
| ^^^^^^^^
...
LL | tags.sort();
| ---- type must be known at this point
|
help: consider giving `tags` an explicit type
|
LL | let mut tags: Vec<_> = lines.iter().map(|e| parse(e)).collect()?;
| ++++++++
```
Previously, it was quite hard to get access to this output because it
was printed to a buffer in memory and then discarded. This output is
already hidden behind libtest's output capturing, we don't need to hide
it twice.
Jonathan Brouwer