Rollup of 6 pull requests #124752
Merged
Rollup of 6 pull requests #124752
Conversation
This file contains 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
Co-authored-by: Trevor Gross <[email protected]> Update library/core/src/primitive_docs.rs Co-authored-by: Trevor Gross <[email protected]> Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <[email protected]> Update library/core/src/primitive_docs.rs Rewrite f16 and f128 hw support comments to match PR feedback I wrote RISC-V allcaps in all cases, and wrote amd64 lowercase in all cases, im not sure if either is the more correct way for either platform, thats just how I normally write them, if theres a precedent elsewhere it should probably be changed to match though. Update library/core/src/primitive_docs.rs Co-authored-by: Jubilee <[email protected]> Update library/core/src/primitive_docs.rs Co-authored-by: Jubilee <[email protected]> Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <[email protected]> Update library/core/src/primitive_docs.rs Remove orphaned doc link and clean up grammar a bit Update library/core/src/primitive_docs.rs
This ensures the version of time used in rustc includes this change: time-rs/time#671. This fix is a necessary prerequisite for rust-lang#99969, which adds FromIterator implementations for Box<str>. Previously, time had an Into::into that resolved to the identity impl followed by a collect::<Result<Box<_>, _>>(). With the new FromIterator implementations for Box<str>, the Into::into resolution is ambiguous and time fails to compile. The fix removes the identity Into::into conversion, allowing time to compile with the new FromIterator implementations. This version of time also matches what cargo recently switched to in rust-lang/cargo#13834.
The code is written in a way to support 32-bit iOS and tvOS ARM devices, for future compatibility even though we currently only have a target for 32-bit iOS ARM.
…uillaumeGomez rustdoc-search: search for references This feature extends rustdoc with syntax and search index information for searching borrow references. Part of rust-lang#60485 ## Preview - [`&mut`](https://notriddle.com/rustdoc-html-demo-11/reference/std/index.html?search=%26mut) - [`&Option<T> -> Option<&T>`](https://notriddle.com/rustdoc-html-demo-11/reference/std/index.html?search=%26Option%3CT%3E%20-%3E%20Option%3C%26T%3E) - [`&mut Option<T> -> Option<&mut T>`](https://notriddle.com/rustdoc-html-demo-11/reference/std/index.html?search=%26mut%20Option%3CT%3E%20-%3E%20Option%3C%26mut%20T%3E) Updated chapter of the book: https://notriddle.com/rustdoc-html-demo-11/reference/rustdoc/read-documentation/search.html ## Motivation See rust-lang#119676 ## Guide-level explanation You can't search by lifetimes, but other than that it's the same syntax references normally use. ## Reference-level description <table> <thead> <tr> <th>Shorthand</th> <th>Explicit names</th> </tr> </thead> <tbody> <tr><td colspan="2">Before this PR</td></tr> <tr> <td><code>[]</code></td> <td><code>primitive:slice</code> and/or <code>primitive:array</code></td> </tr> <tr> <td><code>[T]</code></td> <td><code>primitive:slice<T></code> and/or <code>primitive:array<T></code></td> </tr> <tr> <td><code>!</code></td> <td><code>primitive:never</code></td> </tr> <tr> <td><code>()</code></td> <td><code>primitive:unit</code> and/or <code>primitive:tuple</code></td> </tr> <tr> <td><code>(T)</code></td> <td><code>T</code></td> </tr> <tr> <td><code>(T,)</code></td> <td><code>primitive:tuple<T></code></td> </tr> <tr> <td><code>(T, U -> V, W)</code></td> <td><code>fn(T, U) -> (V, W)</code>, Fn, FnMut, and FnOnce</td> </tr> <tr><td colspan="2">New additions with this PR</td></tr> <tr> <td><code>&</code></td> <td><code>primitive:reference</td> </tr> <tr> <td><code>&mut</code></td> <td><code>primitive:reference<keyword:mut></td> </tr> <tr> <td><code>&T</code></td> <td><code>primitive:reference<T></td> </tr> <tr> <td><code>&mut T</code></td> <td><code>primitive:reference<keyword:mut, T></td> </tr> </tbody> </table> ### Search query grammar <code><pre><strong>borrow-ref = AMP *WS [MUT] *WS [arg]</strong> arg = [type-filter *WS COLON *WS] (path [generics] / slice-like / tuple-like / <strong>borrow-ref</strong>)</pre></code> ``` AMP = "&" MUT = "mut" ``` ## Future direction As described in rust-lang#118194 and rust-lang#119676 * The remaining type expression grammar (this is another step in the type expression grammar: `ReferenceType` is now supported) * Search subtyping and traits
…onur-ozkan Fix bootstrap panic when build from tarball Got this error when build from beta tarball (2024-05-03) regression of rust-lang@6f4f39a panic info: ``` thread 'main' panicked at src/core/builder.rs:583:25: `should_run.paths` should correspond to real on-disk paths - use `alias` if there is no relevant path: src/llvm-project/compiler-rt/lib/crt stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: bootstrap::core::builder::ShouldRun::paths::{{closure}} at ./src/bootstrap/src/core/builder.rs:583:25 3: core::iter::adapters::map::map_fold::{{closure}} at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28 4: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27 5: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9 6: core::iter::traits::iterator::Iterator::for_each at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9 7: alloc::vec::Vec<T,A>::extend_trusted at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17 8: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9 9: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9 10: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9 11: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9 12: core::iter::traits::iterator::Iterator::collect at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9 13: <alloc::collections::btree::set::BTreeSet<T> as core::iter::traits::collect::FromIterator<T>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/collections/btree/set.rs:1191:34 14: core::iter::traits::iterator::Iterator::collect at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9 15: bootstrap::core::builder::ShouldRun::paths at ./src/bootstrap/src/core/builder.rs:578:13 16: bootstrap::core::builder::ShouldRun::path at ./src/bootstrap/src/core/builder.rs:562:9 17: <bootstrap::core::build_steps::llvm::CrtBeginEnd as bootstrap::core::builder::Step>::should_run at ./src/bootstrap/src/core/build_steps/llvm.rs:1174:9 18: bootstrap::core::builder::StepDescription::run::{{closure}} at ./src/bootstrap/src/core/builder.rs:416:25 19: core::iter::adapters::map::map_fold::{{closure}} at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28 20: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27 21: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9 22: core::iter::traits::iterator::Iterator::for_each at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9 23: alloc::vec::Vec<T,A>::extend_trusted at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17 24: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9 25: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9 26: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9 27: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9 28: core::iter::traits::iterator::Iterator::collect at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9 29: bootstrap::core::builder::StepDescription::run at ./src/bootstrap/src/core/builder.rs:414:27 30: bootstrap::core::builder::Builder::run_step_descriptions at ./src/bootstrap/src/core/builder.rs:1047:9 31: bootstrap::core::builder::Builder::execute_cli at ./src/bootstrap/src/core/builder.rs:1028:9 32: bootstrap::Build::build at ./src/bootstrap/src/lib.rs:683:17 33: bootstrap::main at ./src/bootstrap/src/bin/main.rs:79:5 34: core::ops::function::FnOnce::call_once at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5 ```
…r=dtolnay compiler: upgrade time from 0.3.34 to 0.3.36 This ensures the version of `time` used in `rustc` includes this change: time-rs/time#671. This fix is a necessary prerequisite for rust-lang#99969, which adds `FromIterator` implementations for `Box<str>`. Previously, `time` had an `Into::into` that resolved to the identity impl followed by a `collect::<Result<Box<_>, _>>()`. With the new FromIterator implementations for Box<str>, the Into::into resolution is ambiguous and time fails to compile. Thanks to `@dtolnay` for the analysis in rust-lang#99969 (comment). The `time` fix removes the identity `Into::into` conversion, allowing `time` to compile with the new `FromIterator` implementations. This version of `time` also matches what `cargo` recently switched to in rust-lang/cargo#13834.
…r=Mark-Simulacrum Fix unwinding on 32-bit watchOS ARM (v2) This PR is identical to rust-lang#124494, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? Mark-Simulacrum Original PR description: --- Found while doing rust-lang#124491, I wanted to unify the code under `target_vendor = "apple"`, and found that [Clang actually specifies that watchOS ARM 32-bit does not use SjLj](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119). I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so? N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it). `@rustbot` label O-watchos
Stabilize exclusive_range_pattern (v2) This PR is identical to rust-lang#124459, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? ghost Original PR description: --- Stabilization report: rust-lang#37854 (comment) FCP: rust-lang#37854 (comment) Stabilization was blocked by a lint that was merged here: rust-lang#118879 Documentation PR is here: rust-lang/reference#1484 `@rustbot` label +F-exclusive_range_pattern +T-lang
…r=workingjubilee Document That `f16` And `f128` Hardware Support is Limited (v2) This PR is identical to rust-lang#123892, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? ghost Original PR description: --- This adds a small paragraph to the recently added f16 and f128 types explaining that hardware support may be limited, and that performance may suffer as a result of that. I mainly wrote this because I felt it may be useful to express in some form; as a launchpoint for readers of the documentation if they have issues with performance. I tried to word the documentation in a way that doesn't create false assumptions (that f16/f128 is too slow to use, for instance), removing the software implementation part could mislead people to thinking that f16/f128 is only available on some platforms, not all, so I believe it is important to keep in.\ "not all *major* platforms" is specifically said so as to not be redundant, because not all platforms implement many things, but the average rustacean is probably going to be using x86_64 or aarch64 derived ISA's, which is who this documentation is targeted towards. I'm not sure of the best way to word the documentation, or if it should even be added, but I feel like it may be useful to have (potentially in a reworded way, I'm not very confident in the current wording and cannot decide if that is because it is too vague to be useful or too specific to be generally correct).
|
@bors r+ p=5 rollup=never |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 06e88c306a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (7c4ac06): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 673.364s -> 674.302s (0.14%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
f16Andf128Hardware Support is Limited (v2) #124750 (Document Thatf16Andf128Hardware Support is Limited (v2))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup