Rollup of 8 pull requests #152282
Merged
Rollup of 8 pull requests #152282
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`cold_path` has been around unstably for a while and is a rather useful
tool to have. It does what it is supposed to and there are no known
remaining issues, so stabilize it here (including const).
Newly stable API:
// in core::hint
pub const fn cold_path();
I have opted to exclude `likely` and `unlikely` for now since they have
had some concerns about ease of use that `cold_path` doesn't suffer
from. `cold_path` is also significantly more flexible; in addition to
working with boolean `if` conditions, it can be used in `match` arms,
`if let`, closures, and other control flow blocks. `likely` and
`unlikely` are also possible to implement in user code via `cold_path`,
if desired.
and deprecate fetch_update starting 1.99.0
We only run LLDB 1500 in CI. Any test with a min-lldb-version above that is currently ignored. It's not clear any of these tests actually work with that LLDB version, and they definitely don't work on LLDB ~2100. So, ignore them until we fix debuginfo testing.
Because `Cache` is unhelpfully vague.
stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter` and the `core::range` module
…jhpratt Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0 Tracking issue: rust-lang#135894 FCP completed: rust-lang#135894 (comment) ~1.96.0 was chosen because I don't think the remaining month until 1.93.0 becomes beta is enough for the FCP to finish and this to get merged, so 1.94.0 + a couple of versions of leeway: rust-lang#135894 (comment) 1.99 suggested in rust-lang#148590 (comment) Closes rust-lang#135894
…, r=tgross35 Stabilize new inclusive range type and iterator type Part 1 of stabilizing the new range types for rust-lang#125687 stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API: ```rust // in core and std pub mod range; // in core::range pub struct RangeInclusive<Idx> { pub start: Idx, pub last: Idx, } impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ } impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> { pub const fn contains<U>(&self, item: &U) -> bool where Idx: [const] PartialOrd<U>, U: ?Sized + [const] PartialOrd<Idx>; pub const fn is_empty(&self) -> bool where Idx: [const] PartialOrd; } impl<Idx: Step> RangeInclusive<Idx> { pub fn iter(&self) -> RangeInclusiveIter<Idx>; } impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ } impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ } impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ } impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ } pub struct RangeInclusiveIter<A>(/* ... */); impl<A: Step> RangeInclusiveIter<A> { pub fn remainder(self) -> Option<RangeInclusive<A>>; } impl<A: Step> Iterator for RangeInclusiveIter<A> { type Item = A; /* ... */ } impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ } impl<A: Step> FusedIterator for RangeInclusiveIter<A> { } impl<A: Step> IntoIterator for RangeInclusive<A> { type Item = A; type IntoIter = RangeInclusiveIter<A>; /* ... */ } impl ExactSizeIterator for RangeInclusiveIter<u8> { } impl ExactSizeIterator for RangeInclusiveIter<i8> { } unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> { type Output = [T]; /* ... */ } unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> { type Output = str; /* ... */ } ``` I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.
…onathanBrouwer Convert to inline diagnostics in `rustc_parse` This was the most annoying one by far, had to make a few changes to the representation of two errors (no user-facing changes tho), these changes are in separate commits for clarity :) For rust-lang#151366 r? @jdonszelmann
…scii, r=dtolnay feat: Implement `int_from_ascii` for `NonZero<T>` - Tracking issue: rust-lang#134821 This pull request adds `from_ascii` and `from_ascii_radix` methods to `NonZero<T>` that parses a non-zero integer from an ASCII-byte slice (`&[u8]`) with decimal digits or digits in a given base. When using the combination of `int::from_ascii` or `int::from_ascii_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error. `NonZero::<T>::from_str_radix` and `NonZero::<T>::from_str` require a string (`&str`) as a parameter. ```rust // Cannot return `IntErrorKind::Zero` as an error. assert_eq!(NonZero::new(u8::from_ascii(b"0").unwrap()), None); // Can return `IntErrorKind::Zero` as an error. let err = NonZero::<u8>::from_ascii(b"0").unwrap_err(); assert_eq!(err.kind(), &IntErrorKind::Zero); ``` See also rust-lang#152193
…pratt Stabilize `core::hint::cold_path` `cold_path` has been around unstably for a while and is a rather useful tool to have. It does what it is supposed to and there are no known remaining issues, so stabilize it here (including const). Newly stable API: ```rust // in core::hint pub const fn cold_path(); ``` I have opted to exclude `likely` and `unlikely` for now since they have had some concerns about ease of use that `cold_path` doesn't suffer from. `cold_path` is also significantly more flexible; in addition to working with boolean `if` conditions, it can be used in `match` arms, `if let`, closures, and other control flow blocks. `likely` and `unlikely` are also possible to implement in user code via `cold_path`, if desired. Closes: rust-lang#136873 (tracking issue) --- There has been some design and implementation work for making `#[cold]` function in more places, such as `if` arms, `match` arms, and closure bodies. Considering a stable `cold_path` will cover all of these usecases, it does not seem worth pursuing a more powerful `#[cold]` as an alternative way to do the same thing. If the lang team agrees, then: Closes: rust-lang#26179 Closes: rust-lang#120193
…-lto, r=nnethercote Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO Closes rust-lang#138910 The existing linker-plugin-based LTO documentation does not describe the correct usage of full LTO. Specifically, when invoking `rustc` with full LTO, the `-C lto` flag must be passed in addition to `-C linker-plugin-lto`. Also, this PR documents the use of full LTO when linking Rust with Fortran. Unfortunately, LLVM `flang` does not currently support ThinLTO, so full LTO is the only viable option in this case. Toolchain combinations were slightly updated. TODO: - [x] check swiftc compiler. Almost unusable. - [x] check how std lib is actually compiled - [x] add note about LLD and bitcode - [x] report bug to LLVM: llvm/llvm-project#179800 <details> <summary>Swiftc is unusable</summary> https://www.swift.org/install/ gave me LLVM-17. During playing with swift main + rust static library, LLVM-23 removed main :D ```console # thin LTO Rust: rustc --crate-type=staticlib -Clinker-plugin-lto -Copt-level=3 ./ftn.rs # full LTO swift: swiftc -static libftn.a main.swift -lto=llvm-full -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr ./sr > ftn() returned: 77 # thin LTO swift: swiftc -static libftn.a main.swift -lto=llvm-thin -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr ./sr > No output ``` </details>
…er-say-about-the-lldb-version-level, r=Noratrieb Ignore all debuginfo tests for LLDB that we do not run in CI We only run LLDB 1500 in CI. Any test with a min-lldb-version above that is currently ignored. It's not clear any of these tests actually work with that LLDB version, and they definitely don't work on LLDB ~2100. So, ignore them until we fix debuginfo testing. Fixes rust-lang#151966
…cache, r=Zalathar Move `rustc_query_system::cache`. It only defines two types, `Cache` and `WithDepNode`. Neither has anything much to do with queries -- they use `DepNodeIndex`, that's all. This commit moves the module into `rustc_middle`, to where they are used. It also renames the extremely non-descriptive `Cache` as `WithDepNodeCache`. r? @Zalathar
rustbot
added
A-query-system
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
bot
added
merged-by-bors
Contributor
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 06cafcbe08 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
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 06cafcb (parent) -> 8c5605e (this PR) Test differencesShow 2781 test diffsStage 0
Stage 1
Stage 2
(and 313 additional test diffs) Additionally, 2368 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 8c5605e130081cbff57f505c56466538039346b1 --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 |
This was referenced Feb 7, 2026
Collaborator
|
Finished benchmarking commit (8c5605e): comparison URL. Overall result: ✅ 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 (primary -6.4%, secondary 5.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 6.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 473.906s -> 472.649s (-0.27%) |
Contributor
Author
|
The regression looks like noise to me, the improvements are caused by #152235 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
atomic_try_updateand deprecatefetch_updatestarting 1.99.0 #148590 (Stabilizeatomic_try_updateand deprecatefetch_updatestarting 1.99.0)rustc_parse#152235 (Convert to inline diagnostics inrustc_parse)int_from_asciiforNonZero<T>#152267 (feat: Implementint_from_asciiforNonZero<T>)core::hint::cold_path#151576 (Stabilizecore::hint::cold_path)rustc_query_system::cache. #152199 (Moverustc_query_system::cache.)r? @ghost
Create a similar rollup