Rollup of 14 pull requests - #162333
Open
Zalathar wants to merge 77 commits into
Open
Conversation
This updates the rust-version file to 0f33d09.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@0f33d09 Filtered ref: rust-lang/miri@d755e9c Upstream diff: rust-lang/rust@9bb55c8...0f33d09 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
This updates the rust-version file to d9dd070.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@d9dd070 Filtered ref: rust-lang/miri@22d0f58 Upstream diff: rust-lang/rust@0f33d09...d9dd070 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
This updates the rust-version file to d0f2ef5.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@d0f2ef5 Filtered ref: rust-lang/miri@cab8e1d Upstream diff: rust-lang/rust@d9dd070...d0f2ef5 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
add chacha20 target feature bug to trophy case
Installing cargo tools (`cargo install`) without locked dependencies exposes users to supply-chain attacks to all the dependencies of the tool (https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/). Using `cargo install --locked` reduces this risk to a compromise of the tool itself, while using the locked and hashed version of the dependencies. I went through all `rg "cargo install"` hits in the repository and added `--locked` to all but explanatory examples (such as cargo's docs on `cargo install` itself). I validated that those tools publish functioning `Cargo.lock`s with https://gist.github.com/konstin/bcb1169c1c1120c259dca64e777a64d0.
This updates the rust-version file to 17fd5b8.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@17fd5b8 Filtered ref: rust-lang/miri@e69d469 Upstream diff: rust-lang/rust@d0f2ef5...17fd5b8 This merge was created using https://github.com/rust-lang/josh-sync.
…ocked Install cargo tools with locked dependencies
Remove outdated reference to -Zsaturating-float-casts
use `portable_simd` vector types for `f16` tests
This updates the rust-version file to edc52f8.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@edc52f8 Filtered ref: rust-lang/miri@4c181b9 Upstream diff: rust-lang/rust@17fd5b8...edc52f8 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
This updates the rust-version file to 2e2b193.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@2e2b193 Filtered ref: rust-lang/miri@fa4559e Upstream diff: rust-lang/rust@edc52f8...2e2b193 This merge was created using https://github.com/rust-lang/josh-sync.
Add `llvm.x86.aesni.aeskeygenassist` support
miri subtree update Subtree update of `miri` to rust-lang/miri@cb8d705. Created using https://github.com/rust-lang/josh-sync. r? @ghost
bootstrap: use target's LLVM libdir when cross-compiling `Cargo::cargo` adds LLVM's library search path to `rustflags` for `ToolRustcPrivate`/`Codegen` so that tools linking against compiler libraries can find `libLLVM`. However, it always queried `host_llvm_config()`, which resolves to the *host*'s `llvm-config` regardless of the requested `target`. When cross-compiling, this appends the host's LLVM libdir to the target's link flags, which can cause linking to fail. Only use `llvm-config --libdir` when `target` is the host. Otherwise, ensure the `Llvm` step for `target` and derive the libdir from its `root_dir()` instead of invoking `llvm-config`, since the resulting binary may not be executable on the host if it was built for a different target.
…port, r=Amanieu Adds support for AArch64 SVE to inline assembly
…=cjgillot A more readable debug map for IndexMaps Let's ship rust-lang#135527 more. To help future debugging, let us print the maps with a more readable format. r? @cjgillot
…=WaffleLapkin make closures act like MaybeDangling This makes closures (and types like them: coroutines and coroutine closures) act like MaybeDangling. This means that the aliasing model will entirely ignore references and `Box`es passed around as closure captures, removing a pretty subtle footgun that has already caused multiple soundness issues: - The standard library thread spawning logic was unsound because it passed around arbitrary user data in a closure capture. See rust-lang#101983 for details. I doubt that this is the only such unsoundness in the ecosystem, this is just very hard to find -- you need to not only run your code in Miri but also pass very specific types through your API to trigger the UB. - Movable (unpinned) generators can contain mutable references that are reborrowed from other references stored in the same generator. This is currently [unsound](rust-lang#159443). The only way this is sound is if the reborrowed-from references are inside MaybeDangling; without this, moving the generator (which retags its contents) invalidates the reborrowed reference. So at least for generators, we have to do this change anyway one way or another. Here's an example of code that no longer has UB under this PR: ```rust fn invoke(f: impl FnOnce()) { f() } fn main() { let p = Box::leak(Box::new(0i32)); invoke(move || { drop(unsafe { Box::from_raw(p) }); }); } ``` Basically, what we are establishing here is that immediately invoking a closure should be (almost) equivalent to just inlining its body. (There is still a caveat here in that if you capture things that violate their validity invariant, the inlined body might not care but immediately invoking the closure will. But at least for all the subtle questions around aliasing, the two will be equivalent under this PR.) Overall I think the fact that moving a closure / generator will alter its contents (by retagging) is just a bit too subtle. It's already subtle for "normal" types but there at least one can see the type with its fields. For closures, that's all entirely implicit. At the same time, the benefit we get from this at the moment is tiny -- we can only actually tell LLVM about these references if the closure/generator has scalar / scalar-pair representation, which can only happen when it captures at most 2 scalar values. This PR just implements the semantics without updating any docs. I am not sure where we'd document this, given our general lack of documentation around the aliasing model. Still we should t-opsem FCP this PR to ensure we have team consensus for not retagging or requiring reference dereferenceability inside closoures and closure-like types (and then we can involve lang if/when we start making official promises about this). On the implementation side, I realized this by introducing the notion of "maybe-dangling-like" types, so that the semantics is not hard-coded specifically to `MaybeDangling`. This also lets us simplify `ManuallyDrop`, reducing its field nesting a bit, which should help with some of the query limit issues people encountered when we added the extra field nesting. It also means generators get the desired semantics without increasing their field nesting. Cc @WaffleLapkin Fixes rust-lang#159443
…hanBrouwer break rustc_expand-rustc_middle dependency Back in rust-lang#145354 (cc @Kobzol), support for caching derive macros was added. With this, rustc_expand was made to depend on rustc_middle. This PR breaks that dependency so that rustc_expand and rustc_builtin_macros can compile in parallel with rustc_middle. The timing graph goes from this: <img width="451" height="438" alt="image" src="https://github.com/user-attachments/assets/2d48b0d4-443c-4ec8-b4f0-a6412e86a62f" /> to this: <img width="456" height="309" alt="image" src="https://github.com/user-attachments/assets/66519857-fa65-4794-ad66-aa565170e196" /> Note that the interval where we're exclusively compiling rustc_middle has become much shorter. Full graphs here: [cargo-timing-main.html](https://github.com/user-attachments/files/31157361/cargo-timing-main.html) [cargo-timing-expand2.html](https://github.com/user-attachments/files/31157373/cargo-timing-expand2.html) It's somewhat hard to benchmark reliably but a full bootstrap is about 5-10 seconds faster overall, on a machine with an Amd Ryzen 5900x 12-core processor.
… r=JohnTitor std::sys::pal::sgx: fix mismatched alloc/free alignment ### Why the PR? I've got a local `miri` branch that's able to test `x86_64-fortanix-unknown-sgx`, so I can get better assurance about our enclaves. It's now complaining about a bunch of stuff in std :sweat_smile: ### Context 1. `x86_64-fortanix-unknown-sgx` enclaves can request the untrusted host enclave runner to allocate/free memory in userspace and get a pointer to it in return. 2. There's a userspace/enclave space memory split for `x86_64-fortanix-unknown-sgx` enclaves. It's a bit like the userspace/kernel space split, where the kernel doesn't trust pointers from userspace and is very paranoid about copying data to/from userspace. ### Problem In the enclave, `User::new_uninit_bytes` and `User::drop` are requesting the host to alloc/dealloc memory with potentially mismatched alignment, as the enclave side is unconditionally over-aligning on allocation but not doing the same on free. - Ex: `User::<ByteBuffer>` -> `alloc(_, align=8)` -> `drop()` -> `free(_, align=1)` See: <https://github.com/rust-lang/rust/blob/main/library/std/src/sys/pal/sgx/abi/usercalls/alloc.rs> ```rust // Enclave-side impl<T: ?Sized> User<T> where T: UserSafe, { // This function returns memory that is practically uninitialized, but is // not considered "unspecified" or "undefined" for purposes of an // optimizing compiler. This is achieved by returning a pointer from // from outside as obtained by `super::alloc`. fn new_uninit_bytes(size: usize) -> Self { unsafe { // Mustn't call alloc with size 0. let ptr = if size > 0 { // `copy_to_userspace` is more efficient when data is 8-byte aligned let alignment = cmp::max(T::align_of(), 8); // <------------------------- HERE rtunwrap!(Ok, super::alloc(size, alignment)) as _ } else { T::align_of() as _ // dangling pointer ok for size 0 }; if let Ok(v) = crate::panic::catch_unwind(|| T::from_raw_sized(ptr, size)) { User(NonNull::new_userref(v)) } else { rtabort!("Got invalid pointer from alloc() usercall") } } } // ... } // ... impl<T: ?Sized> Drop for User<T> where T: UserSafe, { fn drop(&mut self) { unsafe { let ptr = (*self.0.as_ptr()).0.get(); // vvvvvvvvvvvvv------------------ HERE super::free(ptr as _, size_of_val(&mut *ptr), T::align_of()); } } } ``` This min. alignment optimization was introduced in rust-lang@6f7d193. See below for more details on why. The two usercalls, `super::alloc` and `super::free`, are eventually handled by the host runner. They just delegate to the `System` allocator: See: <https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/enclave-runner-sgx/src/usercalls/mod.rs> ```rust // Host-side / userspace impl<'tcs> IOHandlerInput<'tcs> { // ... #[inline(always)] fn alloc(&self, size: usize, alignment: usize) -> IoResult<*mut u8> { unsafe { // vvvvvvvvv--------------- UNCHANGED let layout = Layout::from_size_align(size, alignment) .map_err(|_| IoErrorKind::InvalidInput)?; if layout.size() == 0 { return Err(IoErrorKind::InvalidInput.into()); } let ptr = System.alloc(layout); if ptr.is_null() { Err(IoErrorKind::Other.into()) } else { Ok(ptr) } } } #[inline(always)] fn free(&self, ptr: *mut u8, size: usize, alignment: usize) -> IoResult<()> { unsafe { // vvvvvvvvv--------------- UNCHANGED let layout = Layout::from_size_align(size, alignment) .map_err(|_| IoErrorKind::InvalidInput)?; if size == 0 { return Ok(()); } Ok(System.dealloc(ptr, layout)) } } // ... } ``` It also appears that `enclave-runner-sgx` assumes that there's no `#[global_allocator]` override (<https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/enclave-runner-sgx/src/usercalls/interface.rs#L333>). For most enclave hosts running stock x86_64-unknown-linux-gnu (glibc malloc), I don't believe this mismatch is currently an issue, since posix `free` ignores the alignment anyway. If you did swap in jemalloc, which does care about the dealloc alignment, then something would definitely go wrong elsewhere, as the you'd have mismatched allocators (`System` above vs `Box<_>`/`Vec<_>` using `Global`). ### Solutions It's not clear that we can round-up the alignment on `free`, since `User::from_raw` exists, and there's various places that call it outside std. We should probably just remove the in-enclave min. alignment until we come up with a more satisfactory solution. My guess is that the right place to do the min. alignment optimization is on enclave-runner-sgx side: <https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/enclave-runner-sgx/src/usercalls/mod.rs#L1596> and other places that hand memory to the SGX enclave. ### Why over-align in the first place? The min. alignment exists for performance reasons (see: `copy_from_userspace`). It's highly preferable if all memory copied from userspace is at least 8 byte aligned, otherwise we have to fallback to a super slow copy routine for the unaligned prefix (and suffix).
Promote `wasm32-wasip3` to a tier 2 target This commit updates documentation, configuration, etc, within the compiler to promote the `wasm32-wasip3` target to tier 2. This means that precompiled binaries will be made available in `rustup` for usage. This target MCP for this change is [rust-lang/compiler-team/100][mcp]. This target requires LLVM 23 which rustc recently has updated to, and then additionally requires wasi-sdk-34 which additionally uses LLVM 23 which was also updated recently. With these ingredients in place the ABI for `wasm32-wasip3` is all lined up and ready to go. These changes were all necessary to bring cooperative threading to the target in the future, but that's not quite ready in the ecosystem yet. I've locally been testing this target and it's done well so far, but I suspect this'll need subsequent bug fixes here and there as other new issues crop up. I don't expect anything major will be necessary, however. [mcp]: rust-lang/compiler-team#1001
coverage: Tidy tests and add some new ones While experimenting with some coverage changes, I noticed that some of our tests are not very useful for diagnosing problems, and that we lack good simple tests for some common Rust constructs.
…precondition-const-eval, r=RalfJung Report precondition violation for `<usize as SliceIndex>::get_unchecked` in const-eval The precondition check was gated on `check_language_ub`, which is disabled in const-eval and Miri, on the grounds that the `assume` below it is language UB that the interpreter will catch anyway. It does catch it, but only as "`assume` called with `false`", which says nothing about what the caller did wrong. This PR instead gates the check on `check_library_ub`, matching `get_unchecked_mut`, so that the interpreter reports the violated precondition. Fixes rust-lang#161611
Add regression test for unsized const parameter default ICE Fixes rust-lang#146084
Fix hashing of span end columns in incremental compilation `stable_hash_span` packs the span start/end line and column together with its length, but the `col_hi` mask was shifted before being applied, so the end column was effectively omitted from the hash. Parenthesize the mask operation so `col_hi` is masked with `0xFF` before being shifted into bits 32..39.
cargotest: add lockfiles The `cargotest` suite clones (specific commit hashes of) some repos from GitHub and builds them. One such repo ([iron](https://github.com/iron/iron)) had no lockfile, and one of its dependencies (`tinyvec`) [pushed an update which failes to compile](Lokathor/tinyvec#225). Add a lockfile for this test to downgrade tinyvec, unblock CI, and prevent this from happening in the future. Also add lockfiles for other tests that were missing them (`diesel` and `stylo`), as not having them risks both broken builds and supply-chain attacks on CI.
bootstrap: Fix broken path for `./x doc compiler/rustc --open` Currently this fails because the correct path contains `rustc_main`, but bootstrap tries to use a path containing `rustc-main` instead. The existing bug is amplified by the fact that currently doing `./x doc rustc_middle --open` for *any* compiler crate will instead document the entire compiler, and then try to open the docs for `rustc-main`, since it's the first crate in the crate list. With this fix, it is at least possible to view the resulting whole-compiler docs. r? Kobzol (or bootstrap)
rustbot
added
A-CI
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
wasm32-wasip3to a tier 2 target #161940 (Promotewasm32-wasip3to a tier 2 target)<usize as SliceIndex>::get_uncheckedin const-eval #161616 (Report precondition violation for<usize as SliceIndex>::get_uncheckedin const-eval)./x doc compiler/rustc --open#162318 (bootstrap: Fix broken path for./x doc compiler/rustc --open)r? @ghost
Create a similar rollup