variances_of currently used search_for_cycle_permutation, which can fail and abort when constructed error result value does not match query input.
This commit changes variances_of to receive a def_id which means it can compute a value without using search_for_cycle_permutation, avoiding the possible abort.
Fixes#127971
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.
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.
Use less `#[macro_use]` in the query system
Macro-rules namespacing and import/export is a bit of a nightmare in general. We can tame it a bit by avoiding `#[macro_use]` as much as possible, and instead putting a `pub(crate) use` after the macro-rules declaration to make the macro importable as a normal item.
I've split this PR into two commits. The first one should hopefully be uncontroversial, while the second commit takes the extra step of declaring `rustc_with_all_queries!` as a macros-2.0 macro, which gives much nicer import/export behaviour, at the expense of having to specify `#[rustc_macro_transparency = "semiopaque"]` to still have access to macro-rules hygiene, because the default macros-2.0 hygiene is too strict here.
There should be no change to compiler behaviour.
---
I stumbled into this while investigating some other changes, such as re-exporting `rustc_middle::query::QueryVTable` or moving the big callback macro out of `rustc_middle::query::plumbing`. I think it makes sense to make this change first, to make other module-juggling tasks easier.
r? nnethercote (or compiler)
Turn label into structured suggestion for `.as_ref()` and `.as_mut()`
```
error[E0382]: use of moved value: `foo`
--> $DIR/as-ref-2.rs:10:14
|
LL | let foo = Some(Struct);
| --- move occurs because `foo` has type `Option<Struct>`, which does not implement the `Copy` trait
LL | let _x: Option<Struct> = foo.map(|s| bar(&s));
| ---------------- `foo` moved due to this method call
LL | let _y = foo;
| ^^^ value used here after move
|
note: `Option::<T>::map` takes ownership of the receiver `self`, which moves `foo`
--> $SRC_DIR/core/src/option.rs:LL:COL
help: consider calling `.as_ref()` to borrow the value's contents
|
LL | let _x: Option<Struct> = foo.as_ref().map(|s| bar(&s));
| +++++++++
help: consider calling `.as_mut()` to mutably borrow the value's contents
|
LL | let _x: Option<Struct> = foo.as_mut().map(|s| bar(&s));
| +++++++++
```
Provide more context on type errors in const context
- 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`
- On default field value using type parameter, provide more context (Fixrust-lang/rust#147748)
docs: remove stale reference to `check_let_chain`
This PR removes a stale reference to `check_let_chain` in the documentation of `compiler/rustc_mir_build/src/thir/pattern/check_match.rs`, as the function was previously removed in rust-lang/rust#146832.
use correct LLVM intrinsic for min/max on floats
The Rust `minnum`/`maxnum` intrinsics are documented to return the other argument when one input is an SNaN. However, the LLVM lowering we currently choose for them does not match those semantics: we lower them to `minnum`/`maxnum`, which (since https://github.com/llvm/llvm-project/pull/172012) is documented to non-deterministically return the other argument or NaN when one input is an SNaN.
LLVM does have an intrinsic with the intended semantics: `minimumnum`/`maximumnum`. Let's use that instead. We can set the `nsz` flag since we treat signed zero ordering as non-deterministic.
Also rename the intrinsics to follow the IEEE 2019 naming, since that is mostly (and in particular, as far as NaN are concerned) now what we do. Also, `minimum_number` and `minimum` are less easy to mix up than `minnum` and `minimum`.
r? @nikic
Cc @tgross35
Fixes https://github.com/rust-lang/rust/issues/149537
Fixes https://github.com/rust-lang/rust/issues/151286
(The issues are only fixed when using the latest supported LLVM, but I don't think we usually track problems specific to people compiling rustc with old versions of LLVM)
Daria Sukhonina