Rollup of 6 pull requests
Successful merges:
- #124148 (rustdoc-search: search for references)
- #124668 (Fix bootstrap panic when build from tarball)
- #124736 (compiler: upgrade time from 0.3.34 to 0.3.36)
- #124748 (Fix unwinding on 32-bit watchOS ARM (v2))
- #124749 (Stabilize exclusive_range_pattern (v2))
- #124750 (Document That `f16` And `f128` Hardware Support is Limited (v2))
r? `@ghost`
`@rustbot` modify labels: rollup
Document That `f16` And `f128` Hardware Support is Limited (v2)
This PR is identical to #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).
Fix unwinding on 32-bit watchOS ARM (v2)
This PR is identical to https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/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
compiler: upgrade time from 0.3.34 to 0.3.36
This ensures the version of `time` used in `rustc` includes this change: https://github.com/time-rs/time/pull/671.
This fix is a necessary prerequisite for #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 https://github.com/rust-lang/rust/pull/99969#issuecomment-2001422230.
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 https://github.com/rust-lang/cargo/pull/13834.
Fix bootstrap panic when build from tarball
Got this error when build from beta tarball (2024-05-03)
regression of 6f4f39a8d5
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
```
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.
Remove suggestion about iteration count in coerce
Fixes#122561
The iteration count-centric suggestion was implemented in PR #100094, but it was based on the wrong assumption that the type mismatch error depends on the number of times the loop iterates. As it turns out, that is not true (see this comment for details: https://github.com/rust-lang/rust/pull/122679#issuecomment-2017432531)
This PR attempts to remedy the situation by changing the suggestion from the one centered on iteration count to a simple suggestion to add a return value.
It should also fix#100285 by simply making it redundant.
This ensures the version of time used in rustc includes this change:
https://github.com/time-rs/time/pull/671.
This fix is a necessary prerequisite for #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 https://github.com/rust-lang/cargo/pull/13834.
Stop `llvm.expect`ing assert terminators
We're putting `llvm.expect` calls before the <https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.TerminatorKind.html#variant.Assert> terminators.
But we don't need them. One of the arms is always to a panic function that's marked `#[cold]`, which is `cold` <https://llvm.org/docs/LangRef.html#function-attributes> in LLVM, which
> When computing edge weights, basic blocks post-dominated by a cold function call are also considered to be cold; and, thus, given low weight.
So even without us emitting the extra intrinsic call, LLVM knows what to expect for the `br`. Thus we can save the (small) effort of emitting it and then LLVM optimizing it out.
r? compiler
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Remove orphaned doc link and clean up grammar a bit
Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
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 <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Rollup of 10 pull requests
Successful merges:
- #124501 (add support to override lldb binary path for ./x test)
- #124573 (add a reference link to the comment of the "cc" and "cmake".)
- #124663 (Enable reusing CI Docker cache when running CI images locally)
- #124690 (Only consider ambiguous goals when finding best obligation for ambiguities)
- #124713 (Update Cargo specific diagnostics in check-cfg)
- #124717 (Implement `do_not_recommend` in the new solver)
- #124718 (Record impl args in the proof tree)
- #124720 (interpret: Drop: always evaluate place)
- #124721 (library/std: Fix build for NetBSD targets with 32-bit `c_long`)
- #124723 (Use correct Hermit links in The `rustc` Book)
r? `@ghost`
`@rustbot` modify labels: rollup
Use correct Hermit links in The `rustc` Book
As is, this documentation links to the old Hermit organization, `hermitcore`, which isn't used anymore.
I've updated the links to point to the new organization. This PR also changes the incorrect "rusty loader" link to point to the new `hermit-rs-template` repo.
(fixes#124722)
library/std: Fix build for NetBSD targets with 32-bit `c_long`
This fixes building `std` for targets like `mipsel-unknown-netbsd`.
If `c_long` is an `i64`, this conversion works with `Into`. But if it's an `i32`, this failed to convert a `u32` to an `i32`.
Implement `do_not_recommend` in the new solver
Put the test into `diagnostic_namespace` test folder even though it's not in the diagnostic namespace, because it should be soon.
r? lcnr
cc `@weiznich`
Update Cargo specific diagnostics in check-cfg
This PR updates the Cargo specific diagnostics for check-cfg/`unexpected_cfgs` lint.
Specifically it update to new url and use the double-column (instead of one) in the Cargo directive suggestion.
`@rustbot` label +F-check-cfg
cc `@weihanglo`
Only consider ambiguous goals when finding best obligation for ambiguities
We don't care about ambiguous goals when reporting true errors, and vice versa for ambiguities.
r? lcnr
Enable reusing CI Docker cache when running CI images locally
When running a CI image locally, e.g. using `DEPLOY=1 src/ci/docker/run.sh dist-x86_64-linux`, it can take a long time until the Docker image is built, which is annoying.
Since we now use proper Docker caching on CI, it should be possible to just `docker pull` the prebuilt image to reuse the cache. We didn't want to do this on CI, since our caching key isn't perfect and it's possible that we can miss some changes, but I think that for local usage it is fine (we could introduce some env. var. to force disable the image download, if needed).
r? `@Mark-Simulacrum`
add support to override lldb binary path for ./x test
When running debuginfo tests I couldn't set custom build of lldb. The `src/bootstrap/src/core/build_steps/test.rs` has "lldb" hardcoded. I ended up hacking `src/bootstrap/src/core/build_steps/test.rs` just to get the tests running the way I wanted.
Then I've found out that we can override `gdb` under [build] section. This PR enables the same for `lldb`
This fixes building `std` for targets like `mipsel-unknown-netbsd`.
If `c_long` is an `i64`, this conversion works with `Into`. But if it's
an `i32`, this failed to convert a `u32` to an `i32`.
interpret, miri: uniform treatments of intrinsics/functions with and without return block
A long time ago we didn't have a `dest: &MPlaceTy<'tcx, Self::Provenance>` for diverging functions, and since `dest` is used so often we special-cased these non-returning intrinsics and functions so that we'd have `dest` available everywhere else. But this has changed a while ago, now only the return block `ret` is optional, and there's a convenient `return_to_block` function for dealing with the `None` case.
So there no longer is any reason to treat diverging intrinsics/functions any different from those that do return.
Use `unchecked_sub` in `split_at`
LLVM currently isn't figuring it out on its own, even in the checked version where it hypothetically could.
Before: <https://rust.godbolt.org/z/PEY38YrKs>
```llvm
bb1: ; preds = %start
%4 = getelementptr inbounds float, ptr %x.0, i64 %n
%5 = sub i64 %x.1, %n
```
After:
```llvm
bb1: ; preds = %start
%4 = getelementptr inbounds float, ptr %x.0, i64 %n
%5 = sub nuw i64 %x.1, %n
```
This is not using the wrapper because there's already a ubcheck covering it, so I don't want this to get a second one once #121571 lands.
---
This is basically the same as #108763, since `split_at` is essentially doing two `get_unchecked`s.
Various improvements to entrypoint code
This moves some code around and adds some documentation comments to make it easier to understand what's going on with the entrypoint logic, which is a bit complicated.
The only change in behavior is consolidating the error messages for unix_sigpipe to make the code slightly simpler.
Improve several `Read` implementations
- `read_to_end` and `read_to_string` for `Cursor`
- Error on OOM in `read_to_string` of `&[u8]` and `VecDeque<u8>`
- Avoid making the slices contiguous in `VecDeque::read_to_string`
- ~`read_exact` and (unstable) `read_buf_exact` for `Take`~
- ~`read_buf` for `UnixStream` and `&UnixStream`~ (moved to #123084)
- `read_to_end` for `ChildStdErr`
Fix ignored tests for formatting
This PR fixes the ignored rules in `rustfmt.toml` that were changed in https://github.com/rust-lang/rust/pull/124613 to allow formatting `rmake.rs` but ended up allowing formatting every Rust files in `tests/`.
The fix is a bit involved since we need to workaround a [`.gitignore` pattern limitation](https://git-scm.com/docs/gitignore#_pattern_format):
> An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined.
Workaround using https://stackoverflow.com/a/5534865
I tested the fix by changing the formatting in an `rmake.rs` and UI test, and verifying that only the `rmake.rs` files were formatted.
Fixes https://github.com/rust-lang/rust/pull/124613#issuecomment-2094094670
cc `@GuillaumeGomez`
r? `@onur-ozkan`
This moves some code around and adds some documentation comments to make
it easier to understand what's going on with the entrypoint logic, which
is a bit complicated.
The only change in behavior is consolidating the error messages for
unix_sigpipe to make the code slightly simpler.
Docs: suggest `uN::checked_sub` instead of check-then-unchecked
As of #124114 it's exactly the same in codegen, so might as well not use `unsafe`.
Note that this is only for *unsigned*, since the overflow conditions for `iN::checked_sub` are more complicated.
Remove an unnecessary cast
Very minor thing, obviously, but I randomly saw this unnecessary cast showing up in the UbChecks, so might as well get rid of it.
We do not coerce `&mut &mut T -> *mut mut T`
Resolves#34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?
