Skip to content

Rollup of 6 pull requests - #160361

Open
jhpratt wants to merge 243 commits into
rust-lang:mainfrom
jhpratt:rollup-TiOn6WJ
Open

Rollup of 6 pull requests#160361
jhpratt wants to merge 243 commits into
rust-lang:mainfrom
jhpratt:rollup-TiOn6WJ

Conversation

@jhpratt

@jhpratt jhpratt commented Aug 1, 2026

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

hoodmane and others added 30 commits April 28, 2026 09:56
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.
…_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.
antoyo and others added 20 commits August 1, 2026 15:49
Only keep minimum required info for `cpuid.def`
…cc_2026-07-24, r=GuillaumeGomez

Subtree cg_gcc sync (2026-07-24)

cc @antoyo @bjorn3

r? ghost
…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
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 1, 2026
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Aug 1, 2026
@jhpratt

jhpratt commented Aug 1, 2026

Copy link
Copy Markdown
Member Author

@bors r+ rollup=never p=7

@rust-bors

rust-bors Bot commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 91709d8 has been approved by jhpratt

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.