Rollup of 6 pull requests - #160361
Closed
jhpratt wants to merge 243 commits into
Closed
Conversation
Previously this was not correctly implemented. Each funclet may need its own terminate block, so this changes the `terminate_block` into a `terminate_blocks` `IndexVec` which can have a terminate_block for each funclet. We key on the first basic block of the funclet -- in particular, this is the start block for the old case of the top level terminate function. Rather than using a catchswitch/catchpad pair, I used a cleanuppad. The reason for the pair is to avoid catching foreign exceptions on MSVC. On wasm, it seems that the catchswitch/catchpad pair is optimized back into a single cleanuppad and a catch_all instruction is emitted which will catch foreign exceptions. Because the new logic is only used on wasm, it seemed better to take the simpler approach seeing as they do the same thing.
…update_cg_gcc_2026-04-29
…_2026-04-29, r=antoyo GCC backend subtree sync r? ghost
This way they also apply to the allocator shim.
Submission to the Apple App Store for iOS no longer requires embedding bitcode, but even back when it did, it needed LLVM bitcode, so GCC wouldn't work anyway.
This is necessary to fix incremental LTO in cg_gcc as well as to do some LTO refactorings I want to do. The actual fix for cg_gcc will be done on the cg_gcc repo to test it in CI.
Move most flags from module_codegen to new_context
`rustc_error_messages` currently depends on `rustc_ast`/`rustc_ast_pretty`. This is odd, because `rustc_error_messages` feels like a very low-level module but `rustc_ast`/`rustc_ast_pretty` do not. The reason is that a few AST types impl `IntoDiagArg` via pretty-printing. `rustc_error_messages` can define `IntoDiagArg` and then impl it for the AST types. But if we invert the dependency we hit a problem with the orphan rule: `rustc_ast` must impl `IntoDiagArg` for the AST types, but that requires calling pretty-printing code which is in `rustc_ast_pretty`, a downstream crate. This commit avoids this problem by just removing the `IntoDiagArg` impls for these AST types. There aren't that many of them, and we can just use `String` in the relevant error structs and use the pretty printer in the downstream crates that construct the error structs. There are plenty of existing examples where `String` is used in error structs. There is now no dependency between `rustc_ast*` and `rustc_error_messages`.
…and, r=bjorn3 Fix: On wasm targets, call `panic_in_cleanup` if panic occurs in cleanup Relies on rust-lang/llvm-project#194. Reland of rust-lang#151771. Previously this was not correctly implemented. Each funclet may need its own terminate block, so this changes the `terminate_block` into a `terminate_blocks` `IndexVec` which can have a terminate_block for each funclet. We key on the first basic block of the funclet -- in particular, this is the start block for the old case of the top level terminate function. Rather than using a catchswitch/catchpad pair, I used a cleanuppad. The reason for the pair is to avoid catching foreign exceptions on MSVC. On wasm, it seems that the catchswitch/catchpad pair is optimized back into a single cleanuppad and a catch_all instruction is emitted which will catch foreign exceptions. Because the new logic is only used on wasm, it seemed better to take the simpler approach seeing as they do the same thing. - [ ] Add test for rust-lang#153948
Pass Session to optimize_and_codegen_fat_lto This is necessary to fix incremental LTO in cg_gcc as well as to do some LTO refactorings I want to do. The actual fix for cg_gcc will be done on the cg_gcc repo to test it in CI.
…henkov Add rlib digest to identify Rust object files This adds a metadata entry to `rlib` archives that lists which members are Rust object files instead of relying on the filename heuristic in `looks_like_rust_object.file`. I also added a fallback to the old behavior for `rlibs` built by older compilers. Part of rust-lang#138243.
Rustup to rustc 1.97.0-nightly (e95e732 2026-05-05)
Handle all modules being serialized during LTO
CrateInfo is only necessary during linking and non-local LTO.
While it was previously defined in Session, it is only ever used with OutputFilenames methods.
…lfJung,scottmcm,saethlin change the type of the argument of `drop_in_place` lang item to `&mut _` We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack: https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392 This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf. This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`: https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833 ------ The rest of the PR is blessing tests and cleaning up things which are not necessary after this change. One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that? I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper) ------- cc @RalfJung Closes rust-lang#154274
Move CrateInfo computation after codegen_crate CrateInfo is only necessary during linking and non-local LTO. Part of rust-lang/compiler-team#908
…-obk Move invocation_temp into OutputFilenames While it was previously defined in Session, it is only ever used with OutputFilenames methods.
Only keep minimum required info for `cpuid.def`
…r=clarfonthey Move `std::io` tests to `alloctests` & add prelude ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 ~~Blocked on: rust-lang#158548~~ ## Description * Moves tests out of `std::io` into `alloctests` now that the relevant items are fully available from `alloc::io`. * Adds documentation to `alloc::io` * Adds prelude modules to `core::io` and `alloc::io`. --- ## Notes * No AI tooling of any kind was used during the creation of this PR.
… r=Amanieu Stabilize passing 128-bit integers via vector registers with `asm!` on x86 tracking issue: rust-lang#133416 reference PR: rust-lang/reference#2313 # Stabilization report ## Summary Stabilize passing 128-bit integers via vector registers with `asm!` on x86 and x86_64: ```rust // Use 128-bit integers with vector registers. let mut v = 0u128; asm!("/* {:x} */", in(xmm_reg) v); asm!("/* {:x} */", out(xmm_reg) v); asm!("/* {:y} */", in(ymm_reg) v); asm!("/* {:y} */", out(ymm_reg) v); asm!("/* {:z} */", in(zmm_reg) v); asm!("/* {:z} */", out(zmm_reg) v); ``` 32-bit and 64-bit integer types can already be passed via vector registers. LLVM has supported 128-bit integers since 2019, see llvm/llvm-project#42502, so `rustc` not supporting them seems like an oversight. This feature is part of [`asm_experimental_reg`](rust-lang#133416). We're not stabilizing that feature as a whole, but only pull out part of it. ## History - rust-lang#151059 ## Open questions None. r? Amanieu
Specialize `advance_by` method of `Fuse` `advance_by` is used a lot internally so it seems important to specialize it.
…htriplett Allow only implementing `Read::read_buf` This PR allows users to only implement `Read::read_buf`, without the need for implementing `Read::read`. `rustc_must_implement_one_of` annotation ensures that **at least** one of the methods is implemented, so that the default impls don't create infinite recursion. Note that `Read::read_buf` is unstable, so this doesn't change anything on stable, there you still need to implement `Read::read`, since you can't implement `Read::read_buf`. Thus, we don't expose `rustc_must_implement_one_of` to stable. r? @thomcc
allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang
Member
Author
|
@bors r+ rollup=never p=7 |
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 2, 2026
Rollup of 6 pull requests Successful merges: - #159844 (Subtree cg_gcc sync (2026-07-24)) - #156527 (Move `std::io` tests to `alloctests` & add prelude) - #159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86) - #160342 (Specialize `advance_by` method of `Fuse`) - #106643 (Allow only implementing `Read::read_buf`) - #159729 (allocations are allowed to grow (but not shrink))
Contributor
|
💔 Test for 61abbb8 failed: CI. Failed job:
|
Contributor
|
This pull request was unapproved due to being closed. |
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
20 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:
std::iotests toalloctests& add prelude #156527 (Movestd::iotests toalloctests& add prelude)asm!on x86 #159525 (Stabilize passing 128-bit integers via vector registers withasm!on x86)advance_bymethod ofFuse#160342 (Specializeadvance_bymethod ofFuse)Read::read_buf#106643 (Allow only implementingRead::read_buf)r? @ghost
Create a similar rollup