Deduplicate higher-ranked lifetime capture errors in impl Trait
Previously, when an `impl Trait` captured multiple higher-ranked
lifetimes from an outer `impl Trait`, the compiler would emit a
separate error for each captured lifetime. This resulted in verbose
and confusing diagnostics, especially in edition 2024 where implicit
captures caused duplicate errors.
This commit introduces error accumulation that collects all capture
spans and lifetime declaration spans, then emits a single consolidated
diagnostic using MultiSpan. The new error shows all captured lifetimes
with visual indicators and lists all declarations in a single note.
r? `@estebank`
Fixes https://github.com/rust-lang/rust/issues/143022
Revert "early return on duplicate span lowerings"
r? `@nnethercote`
reverts rust-lang/rust#149060 because of perf regressions that are still wild to me
std: Use more `unix.rs` code on WASI targets
This commit is a large change to the implementation of filesystem and
other system-related operations on WASI targets. Previously the standard
library explicitly used the `wasi` crate at the 0.11.x version track
which means that it used WASIp1 APIs directly. This meant that `std` was
hard-coded to use WASIp1 syscalls and there was no separate
implementation for the WASIp{2,3} targets, for example. The high-level
goal of this commit is to decouple this interaction and avoid the use of
the `wasi` crate on the WASIp2 target.
Historically when WASIp1 was originally added to Rust the wasi-libc
library was in a much different position than it is today. Nowadays Rust
already depends on wasi-libc on WASI targets for things like memory
allocation and environment variable management. As a libc library it
also has all the functions necessary to implement all filesystem
operations Rust wants. Recently wasi-libc additionally was updated to
use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using
`wasm32-wasip1` APIs. This commit is leveraging this work by enabling
Rust to completely sever the dependence on WASIp1 APIs when compiling
for `wasm32-wasip2`. This is also intended to make it easier to migrate
to `wasm32-wasip3` internally in the future where now only libc need be
updated and Rust doesn't need to explicitly change as well.
The overall premise of this commit is that there's no need for
WASI-specific implementation modules throughout the standard library.
Instead the libc-style bindings already implemented for Unix-like
targets are sufficient. This means that Rust will now be using
libc-style interfaces to interact with the filesystem, for example, and
wasi-libc is the one responsible for translating these POSIX-ish
functions into WASIp{1,2} calls.
Concrete changes here are:
* `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x`
* The implementation of `std::os::wasi::fs`, which was previously
unstable and still is, now has portions gated to only work on the
WASIp1 target which use the `wasi` crate directly. Traits have been
trimmed down in some cases, updated in others, or now present a
different API on WASIp1 and WASIp2. It's expected this'll get further
cleanup in the future.
* The `std::sys::fd::wasi` module is deleted and `unix` is used instead.
* The `std::sys::fs::wasi` module is deleted and `unix` is used instead.
* The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used
instead.
* The `std::sys::pal::{wasip1,wasip2}` modules are now merged together
as their difference is much smaller than before.
* The `std::sys::pal::wasi::time` is deleted and the `unix` variant is
used directly instead.
* The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
* The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
Overall Rust's libstd is effectively more tightly bound to libc when
compiled to WASI targets. This is intended to mirror how it's expected
all other languages will also bind to WASI. This additionally has the
nice goal of drastically reducing the WASI-specific maintenance burden
in libstd (in theory) and the only real changes required here are extra
definitions being added to `libc` (done in separate PRs). This might be
required for more symbols in the future but for now everything should be
mostly complete.
Move the libgccjit.so file in a target directory
Since GCC is not multi-target, we need multiple libgccjit.so. Our solution to have a directory per target so that we can have multiple libgccjit.so.
r? `@Kobzol`
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and adding actual support for `-Cdebuginfo=line-tables-only` rather than treating it the same as `-Cdebuginfo=full`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Improve error message for std integer clamp() if min > max
For rust-lang/rust#142309: change the error message for `Ord::clamp()` for std integer types if min > max to be more useful.
Message is now `min > max. min = {min:?}, max = {max:?}`
Also add `#[track_caller]` to `clamp()`
Assume the returned value in `.filter(…).count()`
Similar to how this helps in `slice::Iter::position`, LLVM sometimes loses track of how high this can get, so for `TrustedLen` iterators tell it what the upper bound is.
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
misc coercion cleanups and handle safety correctly
r? lcnr
### "remove normalize call"
Fixesrust-lang/rust#132765
If the normalization fails we would sometimes get a `TypeError` containing inference variables created inside of the probe used by coercion. These would then get leaked out causing ICEs in diagnostics logic
### "leak check and lub for closure<->closure coerce-lubs of same defids"
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/233
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
return |x| x + 1
}
```
the `|x| x + 1` expr has a type of `Closure(?31t)` which we wind up inferring the RPIT to. The `CoerceMany` `ret_coercion` for the whole `peculiar` typeck has an expected type of `RPIT` (unnormalized). When we type check the `return |x| x + 1` expr we go from the never type to `Closure(?31t)` which then participates in the `ret_coercion` giving us a `coerce-lub(RPIT, Closure(?31t))`.
Normalizing `RPIT` gives us some `Closure(?50t)` where `?31t` and `?50t` have been unified with `?31t` as the root var. `resolve_vars_if_possible` doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a `fn` ptr. cc rust-lang/rust#147193 which also fixes this
New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3
### FCP worthy stuffy
there are some other FCP worthy things but they're in my FCP comment which also contains some analysis of the breaking nature of the previously listed changes in this PR: https://github.com/rust-lang/rust/pull/148602#issuecomment-3503497467
In the inferred type hints, expand the line too long. add config to disable it.
Example
---
```json
{"rust-analyzer.inlayHints.typeHints.hideInferredTypes": true}
```
```rust
use std::collections::HashMap;
fn foo(iter: Vec<Result<HashMap<String, String>, std::io::Error>>) {
let output = iter.into_iter().collect::<Result<Vec<_>, _>>().unwrap();
}
```
**Before this PR**
```rust
let output: Vec<HashMap<String, String>> = iter.into_iter().collect::<Result<Vec<_ = HashMap<String, String>>, _ = Error>>().unwrap();
```
**After this PR**
```rust
let output: Vec<HashMap<String, String>> = iter.into_iter().collect::<Result<Vec<_>, _>>().unwrap();
```
Additional test for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: https://github.com/rust-lang/rust/issues/149069
Accepted ACP: https://github.com/rust-lang/libs-team/issues/695#issuecomment-3549284861
Adds an additional runtime test for `uN::gather_bits` and `uN::scatter_bits` in coretests. They are each other's inverses in a sense, so a shared test can test both with relative ease.
I plan to follow up with optimized implementations for these functions.
CTFE: avoid emitting a hard error on generic normalization failures
Fixesrust-lang/rust#149081.
The fix is quite unsatisfying and should not be necessary, cc rust-lang/rust#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs.
cc ````@rust-lang/types```` I think we should try to fix issue rust-lang/rust#149283 in the near future and then remove this hack again.
I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this:
- we only fetch the MIR in the `eval_to_allocation_raw` query
- figuring out which MIR to use is hard
- dealing with trivial consts is annoying
- need to resolve instances for associated consts
- implementing this by hand is hard
- inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness
- `try_normalize_after_erasing_regions` generally does two things
- deal with ambiguity after inlining
- deal with error tainting issues (please don't, we should stop doing that)
- CTFE could be changed to always silently ignore normalization failures if we're in a generic body
- hides actual bugs <- went with this option
r? types
std: don't call `current_os_id` from signal handler
`current_os_id` is not always async-signal-safe depending on the platform, hence it may not be called from the SIGSEGV handler. Instead, store the thread ID along with the thread name during setup. With rust-lang/rust#144465 merged, this information is available even before the thread main function.
Use `TypingMode::PostAnalysis` in `try_evaluate_const`
As mentioned in https://github.com/rust-lang/rust/pull/148698#discussion_r2541882341, we should use ``TypingMode::PostAnalysis`` for that path.
````@BoxyUwU```` prefer the match in ``try_evaluate_const`` to be exhaustive, so I also included that in this PR :3
Example
---
```rust
fn main() {
let x = &$0
}
```
**Before this PR**
```rust
fn main() {
let x = &loop {
$0
}
}
```
**After this PR**
```rust
fn main() {
let x = &loop {
$0
};
}
```
In `BTreeMap::eq`, do not compare the elements if the sizes are different.
Reverts rust-lang/rust#147101 in library/alloc/src/btree/
rust-lang/rust#147101 replaced some instances of code like `a.len() == b.len() && a.iter().eq(&b)` with just `a.iter().eq(&b)`, but the optimization that PR introduced only applies for `TrustedLen` iterators, and `BTreeMap`'s itertors are not `TrustedLen`, so this theoretically regressed perf for comparing large `BTreeMap`/`BTreeSet`s with unequal lengths but equal prefixes, (and also made it so that comparing two different-length `BTreeMap`/`BTreeSet`s with elements whose `PartialEq` impls that can panic now can panic, though this is not a "promised" behaviour either way (cc rust-lang/rust#149122))
Given that `TrustedLen` is an unsafe trait, I opted to not implement it for `BTreeMap`'s iterators, and instead just revert the change. If someone else wants to audit `BTreeMap`'s iterators to make sure they always return the right number of items (even in the face of incorrect user `Ord` impls) and then implement `TrustedLen` for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright).
Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using `Instant::elapsed`).
In release mode on stable the comparison takes ~23.68µs.
In release mode on beta/nightly the comparison takes ~48.351057ms.
Bring back i686-pc-windows-gnullvm target
rust-lang/rust#148751 inadvertently removed i686-pc-windows-gnullvm std build when migrating to native CI runners. Since this change was not agreed upon, we should bring back prebuilt std builds for that target.
There are a few runners that could do it: dist-aarch64-llvm-mingw, dist-x86_64-llvm-mingw, dist-various-1 and dist-various-2.
dist-x86_64-llvm-mingw already takes slightly over 2 hours, so the faster dist-aarch64-llvm-mingw is a better choice.
We can also use dist-various-x job, they don't have llvm-mingw toolchain, but it's trivial to install one.
