Skip to content

Rollup of 6 pull requests - #163313

Closed
jhpratt wants to merge 13 commits into
rust-lang:mainfrom
jhpratt:rollup-XelspwM
Closed

jhpratt wants to merge 13 commits into
rust-lang:mainfrom
jhpratt:rollup-XelspwM

Conversation

@jhpratt

@jhpratt jhpratt commented Sep 25, 2026

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

beepster4096 and others added 13 commits August 8, 2026 15:20
LLVM 24 removed the -wasm-enable-eh option in favor of relying on
TargetMachine.Options.ExceptionModel == Wasm. We were already setting
ExceptionModel to Wasm on LLVM 24 in PassWrapper.cpp for wasm targets so
this is a no-op on LLVM 24. Further, we already implied the
-wasm-enable-eh flag on LLVM 23, so the explicit pass in
wasm-exceptions-nostd was redundant and can be safely dropped.
A recent change caused LLVM to identify `vpmov*, vpblend*` type
instructions and merges them into single `vblendv*` instructions.
…s, r=oli-obk

Disallow accesses through an Index projection when a sibling ConstantIndex projection has been moved out of

Fixes rust-lang#160525

- Refactored the `LookupResult` enum returned by `MovePathLookup::find`:
   - The `LookupResult::Parent(None)` case is now a separate variant, `LookupResult::None`
   - `LookupResult::Parent` has an additional field containing the variant immediately following the parent move path.
 - Borrowck's `check_if_full_path_is_moved` now checks that new field and if it is `PlaceElem::Index`, it makes sure there are no uninit descendants of the indexed array's move path (which can only be `ConstantIndex` and descendants of those.)
    - `move_path_closest_to` is removed and inlined into `check_if_full_path_is_moved`.
…-obk

Use get to avoid ICE on unresolved imports

Fixes rust-lang#163294

After rust-lang#161349, unresolved imports may not have `import_res`.
rustc_codegen_llvm: catch up with LLVM 24 on wasm exceptions

LLVM 24 [removed](llvm/llvm-project@cf40ab1) the -wasm-enable-eh option in favor of relying on TargetMachine.Options.ExceptionModel == Wasm. We were already setting ExceptionModel to Wasm on LLVM 24 in PassWrapper.cpp for wasm targets so this is a no-op on LLVM 24. Further, we already implied the -wasm-enable-eh flag on LLVM 23, so the explicit pass in wasm-exceptions-nostd was redundant and can be safely dropped.

@rustbot label: +llvm-main
tests: accept more efficient simd output from LLVM 24

A [recent change](llvm/llvm-project@4200a8e) caused LLVM to identify `vpmov*, vpblend*` type instructions and merges them into single `vblendv*` instructions.

An LLM was used to identify the breaking change in the relevant range automatically (and it gave some explanation as to why, which matches the LLVM commit message), but the changes are all mine.

@rustbot label: +llvm-main

(this is the same as rust-lang#162547, which I accidentally perma-closed by having a misfire while cleaning up git branches in my rust repo)
…idation, r=oli-obk

Fix provisional cache invalidation in the old trait solver (ran into probing ICE issue)

Hi I found this issue while trying to fix incremental compilation ICE issue in a ledger system i was working at owrk(luckily it panic early)

I noticed that ! in ProvisionalEvaluationCache::on_failure at compiler/rustc_trait_selection/src/traits/select/mod.rs:3094 was not doing its intended behavior. The documentation says that on_failure should remove provisional cache entries created at or after the failing node, meaning entries where from_dfn >= dfn. The current condition is !eval.from_dfn >= dfn. Since from_dfn is usize and ! binds more tightly than >=; this applies a bitwise NOT to from_dfn before comparing it with dfn. For the small DFN values we normally encountered here, that produces a huge number causing the condition to always be true on_failure then clears the entire provisional cache instead of preserving entries created before the failing node. This PR removes the ! so fn works as is intended behavior makign the comments true, I also compared local compilation times using the old trait solver and emitting metadata only. The median results were:
```

Test case                                     Before                   With ! removed
Regression test for rust-lang#150907                    32.56 ms             32.44 ms
Synthetic cyclic types with an error        32.15 ms           32.18 ms
Synthetic cyclic types without errors      27.15 ms          26.92 ms
```
I tested this on all avilable toolchains, all seem to produce similar results.
This DOES NOT fix the ICE issue it still happens this is just a correction on behavior and that boost performance and then i can fix the ICE issue, The ICE issue I fix by removing the tainted_by_errors() lines 1098-1105 else condition
(introduced by pr  rust-lang#155355  from what i believe was fixing a performance issue so timing is important)that allows caching results that depend on the evaluation stack
This fix plus the removal of the ! makes the existing regression test much slower yet faster than the original issue which was 30s (i believe)
(here is a small sample data i took)
```
Change                                              Time
Baseline                                   0.035 s
Remove the tainted_by_errors() branch       30.59 s
Remove that branch and remove the !         2.73 s
```

While  its not beating the current baseline it does correctly not throw a panic(which has cause issues in our ledger), I would like to fix the ICE issue, but that needs more work if the intention is to equal the .03 time and i heard this trait solver is being deprecrated soon? For now I am keeping this PR focused on the provisional cache invalidation and would like to follow up on the ICE in a separate PR
ty::CoroutineClosure is more a closure than a coroutine

Follow-up to rust-lang#162361.
@rust-lang/opsem It seems to me CoroutineClosure is more like Closure than like Coroutine, hence the change.
(I'm not sure why it is a separate type to begin with.)
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Sep 25, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs 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. labels Sep 25, 2026
@jhpratt

jhpratt commented Sep 25, 2026

Copy link
Copy Markdown
Member Author

@bors r+ p=5 force

@rust-bors

rust-bors Bot commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 6483f7b 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 Sep 25, 2026
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job test-pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] rustc_codegen_llvm test:false 3.405
    Checking rustc_mir_build v0.0.0 (/checkout/compiler/rustc_mir_build)
[RUSTC-TIMING] rustc_hir_analysis test:false 6.246
    Checking rustc_hir_typeck v0.0.0 (/checkout/compiler/rustc_hir_typeck)
error[E0004]: non-exhaustive patterns: `LookupResult::Parent { next_elem: rustc_middle::mir::ProjectionElem::PhantomDeref, .. }` not covered
    --> compiler/rustc_borrowck/src/lib.rs:2079:32
     |
2079 |         let uninit_mpi = match self.move_data.rev_lookup.find(place_span.0) {
     |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pattern `LookupResult::Parent { next_elem: rustc_middle::mir::ProjectionElem::PhantomDeref, .. }` not covered
     |
note: `LookupResult` defined here
    --> compiler/rustc_mir_dataflow/src/move_paths/mod.rs:343:1
     |
 343 | pub enum LookupResult {
     | ^^^^^^^^^^^^^^^^^^^^^
...
 349 |     Parent {
     |     ------ not covered
     = note: the matched value is of type `LookupResult`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
     |
2101 ~             LookupResult::None => bug!("should have move path for every Local"),
2102 ~             LookupResult::Parent { next_elem: rustc_middle::mir::ProjectionElem::PhantomDeref, .. } => todo!(),
     |

For more information about this error, try `rustc --explain E0004`.
[RUSTC-TIMING] rustc_borrowck test:false 5.192
error: could not compile `rustc_borrowck` (lib) due to 1 previous error

@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 Sep 25, 2026
@rust-bors

rust-bors Bot commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

PR #160780, which is a member of this rollup, was unapproved.

This rollup was thus unapproved.

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 25, 2026
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. A-run-make Area: port run-make Makefiles to rmake.rs rollup A PR which is a rollup T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants