Rollup of 11 pull requests - #162148
Conversation
I added this flag back in 2017 to enable benchmarking of the saturating semantics when it was newly implemented and still experimental. But saturation has been the official semantics for float<->int `as` casts for years now. A flag for turning it off no longer serves any purpose, it's just `-Zplease-miscompile-casts` now.
tests/ui/match/match-stack-overflow-72933-.rs crashes on s390x due to hitting stack_size limit. changing the size to 17MB the crash.
Reduce the scope of `unsafe` blocks that are not yet documented by moving safe operations out of the blocks, making it easier to add the missing documentation in the future.
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
Update `icu_list` dependency to 2.3 This removes the `icu_collections` transitive dependency, and uses the smaller `icu_locale_fallback` instead of `icu_locale`. r? manishearth
…isDenton change DEFAULT_STACK_SIZE to be 32MB on s390x `tests/ui/match/match-stack-overflow-72933-.rs` crashes on s390x due to hitting stack_size limit(rust-lang#161742). changing the size to 32MB on s390x fixes the crash.
Diverse offload fixes `HostMetadata` pass skips linking. Now, `offload_kernel` macro lowers to `core` instead of `std`. closes: rust-lang#161703 r? @ZuseZ4
…RalfJung Remove -Zsaturating-float-casts flag I added this flag back in 2017 (rust-lang#45205) to enable benchmarking of the saturating semantics when it was newly implemented and still experimental. But saturation has been the official semantics for float<->int `as` casts for years now. A flag for turning it off no longer serves any purpose, it's just `-Zplease-miscompile-casts` now.
…t-mismatch-ice, r=estebank Fix ICE of getting item name from RPITIT Fixes rust-lang#161915 RPITIT projections use anonymous associated type and have no item name.
Rework `next_power_of_two` to always be `1 << …` r? @clarfonthey Who accidentally nerd-sniped me by mentioning rust-lang#161069 This obviates that PR by reworking the `(checked_)next_power_of_two` logic to calculate the necessary exponent e, then return 2ᵉ, so it's structurally obvious from the IR -- the `shl nuw 1, …` instruction -- that it's always a power of two. As always, the reason this is tricky is because shifts don't work for `<< Self::BITS`. The previous code handled that by checking `self <= 1` first, and thus doing a `-1 >> n` where `n < BITS`. This code instead flips the check: it looks up-front for a value that will wrap (an input above `1 << (BITS - 1)`) and thus by excluding those cases the calculated `1 << n` always has `n < BITS`. And the codegen tests show that, without needing any `llvm.assume`s, LLVM can take advantage of it to do things like rewriting `%` to masking. Plus the overflow check optimizes out for constrained inputs like slice lengths.
…nthey Change some `Infallible` to `!` in std I believe this desirable since we recommend `!` over `Infallible`, so std follows its own advice. Most changes are to unstable features, but not all. Similar changes in compiler have to wait for a bootstrap update.
… r=mejrs Remove `gate_check` from `AttributeStability::Unstable` Based on the idea from rust-lang#162051 (comment) r? @mejrs
…oc, r=clarfonthey `alloc` crate: shrink undocumented `unsafe` blocks Reduce the scope of `unsafe` blocks that are not yet documented by moving safe operations out of the blocks, making it easier to add the missing documentation in the future.
make it clear that Range cannot represent arbitrary ranges This seems like a useful clarification, though it is already heavily implied by the first sentence in the docs. What is less clear to me is what type one *should* use to represent arbitrary ranges. Should we recommend `(Bound<T>, Bound<T>)` for that purpose? It seems best-stuied, and is already used for that purpose by the btree collections and in rust-lang#136903. However, I suspect it is also common that one wants to represent an arbitrary range that's bounded on both sides. `RangeInclusive` can represent all those (though representing the empty range is a bit awkward), `Range` cannot. Nominating for t-libs to get their general vibe on what we want to recommend here, if anything.
This comment has been minimized.
This comment has been minimized.
Rollup of 11 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 a433023 (parent) -> 5db7f4b (this PR) Test differencesShow 1131 test diffsStage 1
Stage 2
Additionally, 1108 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 5db7f4be8a36c1b8ae19299469e2be2b0f052c21 --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 |
|
Finished benchmarking commit (5db7f4b): 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 -2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -5.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 473.301s -> 475.082s (0.38%) |
|
📌 Perf builds for each rolled up PR:
parent commit: a4330234a7 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Successful merges:
--printoption #151618 (rustdoc: add--printoption)icu_listdependency to 2.3 #161287 (Updateicu_listdependency to 2.3)next_power_of_twoto always be1 << …#161209 (Reworknext_power_of_twoto always be1 << …)Infallibleto!in std #162073 (Change someInfallibleto!in std)gate_checkfromAttributeStability::Unstable#162086 (Removegate_checkfromAttributeStability::Unstable)alloccrate: shrink undocumentedunsafeblocks #162102 (alloccrate: shrink undocumentedunsafeblocks)r? @ghost
Create a similar rollup