Use root obligation on E0277 for some cases
When encountering trait bound errors that satisfy some heuristics that tell us that the relevant trait for the user comes from the root obligation and not the current obligation, we use the root predicate for the main message.
This allows to talk about "X doesn't implement Pattern<'_>" over the most specific case that just happened to fail, like "char doesn't implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`
The heuristics are:
- the type of the leaf predicate is (roughly) the same as the type from the root predicate, as a proxy for "we care about the root"
- the leaf trait and the root trait are different, so as to avoid talking about `&mut T: Trait` and instead remain talking about `T: Trait` instead
- the root trait is not `Unsize`, as to avoid talking about it in `tests/ui/coercion/coerce-issue-49593-box-never.rs`.
```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
--> $DIR/root-obligation.rs:6:38
|
LL | .filter(|c| "aeiou".contains(c))
| -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
| |
| required by a bound introduced by this call
|
= note: required for `&char` to implement `FnOnce<(char,)>`
= note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
--> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
|
LL | .filter(|c| "aeiou".contains(*c))
| +
```
Fix#79359, fix#119983, fix#118779, cc #118415 (the suggestion needs to change), cc #121398 (doesn't fix the underlying issue).
Adjust error `yield`/`await` lowering
Adjust the lowering of `yield`/`await` outside of their correct scopes so that we no longer make orpan HIR exprs.
Previously, `yield EXPR` would be lowered directly to `hir::TyKind::Error` (which I'll call `<error>`) which means that `EXPR` was not present in the HIR, but now we lower it to `{ EXPR; <error> }` so that `EXPR` is not orphaned.
Fixes#121096
Add a scheme for moving away from `extern "rust-intrinsic"` entirely
All `rust-intrinsic`s can become free functions now, either with a fallback body, or with a dummy body and an attribute, requiring backends to actually implement the intrinsic.
This PR demonstrates the dummy-body scheme with the `vtable_size` intrinsic.
cc https://github.com/rust-lang/rust/issues/63585
follow-up to #120500
MCP at https://github.com/rust-lang/compiler-team/issues/720
Rollup of 10 pull requests
Successful merges:
- #120976 (constify a couple thread_local statics)
- #121683 (Fix LVI tests after frame pointers are enabled by default)
- #121703 (Add a way to add constructors for `rustc_type_ir` types)
- #121732 (Improve assert_matches! documentation)
- #121928 (Extract an arguments struct for `Builder::then_else_break`)
- #121939 (Small enhancement to description of From trait)
- #121968 (Don't run test_get_os_named_thread on win7)
- #121969 (`ParseSess` cleanups)
- #121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.)
- #121994 (Update platform-support.md with supported musl version)
r? `@ghost`
`@rustbot` modify labels: rollup
Extract an arguments struct for `Builder::then_else_break`
Most of this method's arguments are usually or always forwarded as-is to recursive invocations.
Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call.
---
While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments.
I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.
Add a way to add constructors for `rustc_type_ir` types
Introduces a module called `rustc_type_ir`, in which we can place traits which are named `Ty`/`Region`/`Const`/etc. which expose constructors for the `rustc_type_ir` types. This means we can construct things `Interner::Ty` with `Ty::new_x(...)`, which is needed to uplift the new trait solver into an interner-agnostic crate.
These traits are placed into a *separate* module because they're only intended to be used in interner-agnostic code, and they should mirror the constructors that are provided by the inherent constructor methods in `rustc_middle`.
Putting this up for vibe-check mostly. I haven't copied over any of the type constructors, except for one to create bound types for use in the canonicalizer.
r? lcnr
Existing names for values of this type are `sess`, `parse_sess`,
`parse_session`, and `ps`. `sess` is particularly annoying because
that's also used for `Session` values, which are often co-located, and
it can be difficult to know which type a value named `sess` refers to.
(That annoyance is the main motivation for this change.) `psess` is nice
and short, which is good for a name used this much.
The commit also renames some `parse_sess_created` values as
`psess_created`.
Add a new `wasm32-wasip1` target to rustc
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
Rollup of 3 pull requests
Successful merges:
- #121130 (Suggest moving definition if non-found macro_rules! is defined later)
- #121912 (Properly deal with GATs when looking for method chains to point at)
- #121927 (Add a proper `with_no_queries` to printing)
r? `@ghost`
`@rustbot` modify labels: rollup
Most of this method's arguments are usually or always forwarded as-is to
recursive invocations.
Wrapping them in a dedicated struct allows us to document each struct field,
and lets us use struct-update syntax to indicate which arguments are being
modified when making a recursive call.
Properly deal with GATs when looking for method chains to point at
Fixes#121898.
~~While it prevents an ICE and the structured suggestion is correct, the method chain diagnostic notes are weird / useless / incorrect judging by a quick look. I guess I should improve that in this PR.~~ Sufficiently taken care of.
r? estebank or compiler-errors (#105332, #105674).
Rollup of 5 pull requests
Successful merges:
- #121248 (Move some tests)
- #121528 (Consider middle segments of paths in `unused_qualifications`)
- #121749 (Don't lint on executable crates with `non_snake_case` names)
- #121935 (library/ptr: mention that ptr::without_provenance is equivalent to deriving from the null ptr)
- #121945 (Run some ui-fulldeps tests on stage 1 again)
r? `@ghost`
`@rustbot` modify labels: rollup
Consider middle segments of paths in `unused_qualifications`
Currently `unused_qualifications` looks at the last segment of a path to see if it can be trimmed, this PR extends the check to the middle segments also
```rust
// currently linted
use std::env::args();
std::env::args(); // Removes `std::env::`
```
```rust
// newly linted
use std::env;
std::env::args(); // Removes `std::`
```
Paths with generics in them are now linted as long as the part being trimmed is before any generic args, e.g. it will now suggest trimming `std::vec::` from `std::vec::Vec<usize>`
Paths with any segments that are from an expansion are no longer linted
Fixes#100979Fixes#96698
```
error[E0599]: no method named `map` found for struct `Vec<bool>` in the current scope
--> $DIR/vec-on-unimplemented.rs:3:23
|
LL | vec![true, false].map(|v| !v).collect::<Vec<_>>();
| ^^^ `Vec<bool>` is not an iterator
|
help: call `.into_iter()` first
|
LL | vec![true, false].into_iter().map(|v| !v).collect::<Vec<_>>();
| ++++++++++++
```
We used to provide some help through `rustc_on_unimplemented` on non-`impl Trait` and non-type-params, but this lets us get rid of some otherwise unnecessary conditions in the annotation on `Iterator`.
When encountering trait bound errors that satisfy some heuristics that
tell us that the relevant trait for the user comes from the root
obligation and not the current obligation, we use the root predicate for
the main message.
This allows to talk about "X doesn't implement Pattern<'_>" over the
most specific case that just happened to fail, like "char doesn't
implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`
The heuristics are:
- the type of the leaf predicate is (roughly) the same as the type
from the root predicate, as a proxy for "we care about the root"
- the leaf trait and the root trait are different, so as to avoid
talking about `&mut T: Trait` and instead remain talking about
`T: Trait` instead
- the root trait is not `Unsize`, as to avoid talking about it in
`tests/ui/coercion/coerce-issue-49593-box-never.rs`.
```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
--> $DIR/root-obligation.rs:6:38
|
LL | .filter(|c| "aeiou".contains(c))
| -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
| |
| required by a bound introduced by this call
|
= note: required for `&char` to implement `FnOnce<(char,)>`
= note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
--> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
|
LL | .filter(|c| "aeiou".contains(*c))
| +
```
Fix#79359, fix#119983, fix#118779, cc #118415 (the suggestion needs
to change).
Add new `pattern_complexity` attribute to add possibility to limit and check recursion in pattern matching
Needed for https://github.com/rust-lang/rust-analyzer/issues/9528.
This PR adds a new attribute only available when running rust testsuite called `pattern_complexity` which allows to set the maximum recursion for the pattern matching. It is quite useful to ensure the complexity doesn't grow, like in `tests/ui/pattern/usefulness/issue-118437-exponential-time-on-diagonal-match.rs`.
r? `@Nadrieril`
