Rollup of 9 pull requests - #152279
Closed
JonathanBrouwer wants to merge 30 commits into
Closed
Conversation
`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
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>
…const-stable-indirect, r=jonathanbrouwer Port `rustc_intrinsic_const_stable_indirect` and `rustc_intrinsic` to the new attribute parser r? @JonathanBrouwer
…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
…ouwer Port some attributes to the attr parser Tracking issue: rust-lang#131229 r? @JonathanBrouwer
Member
Author
|
@bors r+ rollup=never p=5 |
rustbot
added
A-attributes
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
☔ The latest upstream changes (presumably #152274) made this pull request unmergeable. Please resolve the merge conflicts. This pull request was unapproved. |
rustbot
removed
the
S-waiting-on-author
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
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_intrinsic_const_stable_indirectandrustc_intrinsicto the new attribute parser #152168 (Portrustc_intrinsic_const_stable_indirectandrustc_intrinsicto the new attribute parser)rustc_query_system::cache. #152199 (Moverustc_query_system::cache.)r? @ghost
Create a similar rollup