Rollup of 8 pull requests - #162046
Conversation
… implementations
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.
…rk-Simulacrum libcore: expose volatile atomic operations Tracking issue: rust-lang#158947 ACP: rust-lang/libs-team#801 @rust-lang/opsem @Darksonn @ojeda help with the docs would be appreciated :) (I figured kernel folks would have things to say about the DMA usecase that I allude to in my example.) Unlike in the ACP, I called the operations `load_volatile` instead of `volatile_load`, to be consistent with the existing `read_volatile` that also makes `volatile` a suffix rather than a prefix (and same for stores).
…r=JohnTitor
Use better generic type parameter names for `Extend` and `FromIterator`
Change
```rs
pub trait Extend<A> {
fn extend<T: IntoIterator<Item = A>>(&mut self, iter: T);
…
}
```
to
```rs
pub trait Extend<T> {
fn extend<I: IntoIterator<Item = T>>(&mut self, iter: I);
…
}
```
to be more consistent with common use of `T` as the item type in containers, and their `Extend` impls; and use `I` as the name for the `IntoIterator` type.
also do the basically the same thing for `FromIterator<A>`→`FromIterator<T>` as well
cases of these parameters in trait impls for the abovementioned traits.
These changes obviously don't change/break behavior of the traits and its users, but the improve the way the documentation of the traits renders (the improvement is the more sensible and more consistent names for the parameters). The only downside I'm aware of (besides that this is touching quite a few files..) is that this does affect some link anchor names in *some* cases. E.g.
```diff
- impl<A, V: FromIterator<A>> FromIterator<Option<A>> for Option<V> {
+ impl<T, V: FromIterator<T>> FromIterator<Option<T>> for Option<V> {
```
would mean that [doc.rust-lang.org/core/iter/trait.FromIterator.html#impl-FromIterator<Option\<A>>-for-Option\<V>](https://doc.rust-lang.org/core/iter/trait.FromIterator.html#impl-FromIterator%3COption%3CA%3E%3E-for-Option%3CV%3E) no longer works, as it changes `…#impl-FromIterator<Option<A>>-for-Option<V>` to `…#impl-FromIterator<Option<T>>-for-Option<V>`
…_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
…op, r=khyperia Remove unused `perform_locally_with_next_solver` A small cleanup. Followup of rust-lang#160982 (comment)
…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
…or, r=nnethercote Make the LLVM version mismatch ICE a fatal error It was pointed out to me that the diatnostic in rust-lang#161788 has the usual ICE messages about how this is a bug and we'd appreciate a report. But it isn't, and a fatal error is a better way to report the problem. Manually tested on MacOS: ``` $ export DYLD_LIBRARY_PATH=/opt/homebrew/opt/llvm@21/lib $ rustc +stage1 --print=sysroot error: LLVM version mismatch: this compiler was built for LLVM 23, but LLVM 21.1.8 was found at /opt/homebrew/Cellar/llvm@21/21.1.8/lib/libLLVM.dylib $ unset DYLD_LIBRARY_PATH $ rustc +stage1 --print=sysroot /Users/ben.kimock/rust/build/aarch64-apple-darwin/stage1 ```
… r=Zalathar LLVM wrapper cleanups Details in individual commits. r? @Zalathar
…er, r=nnethercote _ an unused parameter Followup to rust-lang#161788 addressing review feedback. r? @nnethercote @bors rollup
|
@bors r+ p=5 |
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
Rollup of 8 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple-1 try-job: aarch64-apple-2 try-job: x86_64-mingw-1 try-job: i686-msvc-1 try-job: i686-msvc-2
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing be4b6a9 (parent) -> 45f215f (this PR) Test differencesShow 1509 test diffsStage 1
Stage 2
Additionally, 1504 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 45f215f136e00d8a74c69afde2f71be3f16837cf --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
📌 Perf builds for each rolled up PR:
parent commit: be4b6a99a3 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (45f215f): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.6%, secondary 5.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 474.007s -> 475.395s (0.29%) |
|
(The artifact size result is an already fixed issue in rustc-perf, ignore that.) |
Successful merges:
ExtendandFromIterator#161379 (Use better generic type parameter names forExtendandFromIterator)perform_locally_with_next_solver#161956 (Remove unusedperform_locally_with_next_solver)TypeOutlivesgoal fails #162026 (Emit delayed bug instead of ICEing whenTypeOutlivesgoal fails)r? @ghost
Create a similar rollup