Skip to content

Rollup of 3 pull requests - #162041

Closed
JonathanBrouwer wants to merge 9 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-f3oHme8
Closed

Rollup of 3 pull requests#162041
JonathanBrouwer wants to merge 9 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-f3oHme8

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

Dnreikronos and others added 9 commits August 28, 2026 10:08
HIR writeback already normalizes closure types. Reuse that result instead of normalizing again in a temporary inference context that would drop region constraints.
HIR writeback already normalizes closure types. Restore alias rigidity after identity instantiation instead of running the solver again while building MIR.
Document when changes to the typing mode or parameter environment make rigidness stale, and when compatible mode groups may reuse it.
Unlike `LLVMTargetMachineRef`, `LLVMTwineRef` and `LLVMSMDiagnosticRef`
are not LLVM-C types and so don't need the wrap/unwrap conversions.
…_rigidity, r=adwinwhite

borrowck: Restore alias rigidity from HIR typeck

Follow-up to rust-lang#161012. This came out of the review thread here:
rust-lang#161012 (comment)

Borrowck was normalizing the closure type again in a fresh inference context. HIR writeback had already done that work. EarlyBinder only marked the aliases as non-rigid again because it has to be conservative. If the second normalization creates region constraints, they disappear with the temporary context.

I first thought normalizing again here was fine. After tracing the type back through writeback, I think it makes more sense to trust the result from HIR typeck. Borrowck now restores the rigid flag, and the IsRigid docs explain that this state can carry into borrowck and when it needs to be reset.

Tested with the coroutine regression and tidy.

cc @adwinwhite @lcnr
…white

Emit delayed bug instead of ICEing when `TypeOutlives` goal fails

Fixes rust-lang#161527

They can actually fail with the next-solver 😄

https://github.com/rust-lang/rust/blob/2e071b28ef7e8a066b49a179e1da753c53500c62/compiler/rustc_next_trait_solver/src/solve/mod.rs#L88-L93

I have once considered tinkering proof tree/`find_best_leaf_obligation` to make it suggest the failed normalization goal but I doubt it worths the extra complexity, since we prolly already have other failing obligations in these cases

r? adwinwhite
… r=Zalathar

LLVM wrapper cleanups

Details in individual commits.

r? @Zalathar
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 31, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 31, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@bors r+ p=5

@rust-bors

rust-bors Bot commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 080dac4 has been approved by JonathanBrouwer

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 31, 2026
@jhpratt jhpratt closed this Aug 31, 2026
@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 31, 2026
@rust-bors

rust-bors Bot commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

@JonathanBrouwer

Copy link
Copy Markdown
Member Author

Just testing, please ignore :3
@rust-timer build 93322cc benchmarks=syn-2.0.101

@rust-timer

This comment has been minimized.

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (93322cc): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: missing data
Artifact size: 402.86 MiB -> 402.81 MiB (-0.01%)

@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@rust-timer build 93322cc benchmarks=doesntexist,alsodoesnt

@rust-timer

Copy link
Copy Markdown
Collaborator

Unknown compile-time benchmark: doesntexist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants