std: Set `has_reliable_f16` to false for MIPS targets in build.rs
This PR makes std tests link for MIPS again (they broke with https://github.com/rust-lang/rust/pull/126608) by avoiding the following link errors. Step-by-step instructions on how to reproduce these errors in docker can be found below.
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17edc3E+0x38): undefined reference to `__gnu_f2h_ieee'
std.9e27ea-cgu.12:(.text._ZN3std3num8test_num17hdc3E+0x38): undefined reference to `__gnu_h2f_ieee'
This PR just adds one line of config in existing f16 infrastructure. It also disables four doctests that fails with the same link errors.
## Step-by-step to reproduce linking error
1. Prepare:
```sh
docker run -it ubuntu:24.10
apt update && apt install -y \
libc6-mips-cross \
libc6-mipsel-cross \
libc6-mips64-cross \
libc6-mips64el-cross \
gcc-mips-linux-gnu \
gcc-mipsel-linux-gnu \
gcc-mips64-linux-gnuabi64 \
gcc-mips64el-linux-gnuabi64 \
git curl python3 build-essential
git clone --depth 1 https://github.com/rust-lang/rust.git
cd rust
```
2. Try to link std tests for any of these 4 MIPS targets by running any one of these commands:
```sh
CC_mips_unknown_linux_gnu=mips-linux-gnu-gcc \
CARGO_TARGET_MIPS_UNKNOWN_LINUX_GNU_LINKER=mips-linux-gnu-gcc \
./x test library/std --target mips-unknown-linux-gnu
CC_mipsel_unknown_linux_gnu=mipsel-linux-gnu-gcc \
CARGO_TARGET_MIPSEL_UNKNOWN_LINUX_GNU_LINKER=mipsel-linux-gnu-gcc \
./x test library/std --target mipsel-unknown-linux-gnu
CC_mips64_unknown_linux_gnuabi64=mips64-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64_UNKNOWN_LINUX_GNUABI64_LINKER=mips64-linux-gnuabi64-gcc \
./x test library/std --target mips64-unknown-linux-gnuabi64
CC_mips64el_unknown_linux_gnuabi64=mips64el-linux-gnuabi64-gcc \
CARGO_TARGET_MIPS64EL_UNKNOWN_LINUX_GNUABI64_LINKER=mips64el-linux-gnuabi64-gcc \
./x test library/std --target mips64el-unknown-linux-gnuabi64
```
### Expected
No link error. After this PR there are no link errors.
### Actual
```
error: linking with `mips-linux-gnu-gcc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "mips-linux-gnu-gcc" "/tmp/rustcEtKsay/symbols.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.00.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.01.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.02.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.03.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.04.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.05.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.06.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.07.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.08.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.09.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.10.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.11.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.13.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.14.rcgu.o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.15.rcgu.o" "-Wl,--as-needed" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_xorshift-deb32232a867c543.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand-5a391600dce9d98f.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/librand_core-a11cfba3d86c5298.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libtest-65b05caf5a9b99a4.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libgetopts-ba692b2f798aef60.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/libunicode_width-20ec8b475126cb0b.rlib" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib/librustc_std_workspace_std-c17f739fee51cc86.rlib" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lstd-124ee57a4c00deda" "-Wl,-Bstatic" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/libcompiler_builtins-bd55a137b89bc81f.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/mips-unknown-linux-gnu/lib" "-o" "/rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib"
= note: /usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: /rust/build/x86_64-unknown-linux-gnu/stage1-std/mips-unknown-linux-gnu/release/deps/std-1cffa50fa8c43b63.std.9ee227e919a554fa-cgu.12.rcgu.o: in function `std::num::test_num':
std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x38): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x3c): undefined reference to `__gnu_f2h_ieee'
/usr/lib/gcc-cross/mips-linux-gnu/12/../../../../mips-linux-gnu/bin/ld: std.9ee227e919a554fa-cgu.12:(.text._ZN3std3num8test_num17haed2ea710c1afdc3E+0x44): undefined reference to `__gnu_h2f_ieee'
...
collect2: error: ld returned 1 exit status
error: could not compile `std` (lib test) due to 1 previous error
```
Mark format! with must_use hint
Uses unstable feature https://github.com/rust-lang/rust/issues/94745
Part of #126475
First contribution to rust, please let me know if the blessing of tests is correct
Thanks `@bjorn3` for the help
Rollup of 8 pull requests
Successful merges:
- #127179 (Print `TypeId` as hex for debugging)
- #127189 (LinkedList's Cursor: method to get a ref to the cursor's list)
- #127236 (doc: update config file path in platform-support/wasm32-wasip1-threads.md)
- #127297 (Improve std::Path's Hash quality by avoiding prefix collisions)
- #127308 (Attribute cleanups)
- #127354 (Describe Sized requirements for mem::offset_of)
- #127409 (Emit a wrap expr span_bug only if context is not tainted)
- #127447 (once_lock: make test not take as long in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
Describe Sized requirements for mem::offset_of
The container doesn't have to be sized, but the field must be sized (at least until https://github.com/rust-lang/rust/issues/126151 is stable).
Print `TypeId` as hex for debugging
In <https://github.com/rust-lang/rust/pull/127134>, the `Debug` impl for `TypeId` was changed to print a single integer rather than a tuple. Change this again to print as hex for more concise and consistent formatting, as was suggested.
Result:
TypeId(0x1378bb1c0a0202683eb65e7c11f2e4d7)
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
offset_from, offset: clearly separate safety requirements the user needs to prove from corollaries that automatically follow
By landing https://github.com/rust-lang/rust/pull/116675 we decided that objects larger than `isize::MAX` cannot exist in the address space of a Rust program, which lets us simplify these rules.
For `offset_from`, we can even state that the *absolute* distance fits into an `isize`, and therefore exclude `isize::MIN`. This PR also changes Miri to treat an `isize::MIN` difference like the other isize-overflowing cases.
Add `new_range_api` for RFC 3550
Initial implementation for #125687
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types.
Tracking issues:
- https://github.com/rust-lang/rust/issues/123741
- https://github.com/rust-lang/rust/issues/125687
Improve readability of some fmt code examples
Some indent was weird. Some examples were too long (overall better to keep it to maximum 80 columns, but only changed the most outstanding ones).
r? ```@Amanieu```
Improve dead code analysis
Fixes#120770
1. check impl items later if self ty is private although the trait method is public, cause we must use the ty firstly if it's private
2. mark the adt live if it appears in pattern, like generic argument, this implies the use of the adt
3. based on the above, we can handle the case that private adts impl Default, so that we don't need adding rustc_trivial_field_reads on Default, and the logic in should_ignore_item
r? ``@pnkfelix``
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC.
Having `From` is highly convenient and the assertion is unlikely to be a problem in practice.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types,
and most other trait impls delegate to the old rage types as well.
Also includes an `.iter()` shorthand for `.clone().into_iter()`
Optimize SipHash by reordering compress instructions
This PR optimizes hashing by changing the order of instructions in the sip.rs `compress` macro so the CPU can parallelize it better. The new order is taken directly from Fig 2.1 in [the SipHash paper](https://eprint.iacr.org/2012/351.pdf) (but with the xors moved which makes it a little faster). I attempted to optimize it some more after this, but I think this might be the optimal instruction order. Note that this shouldn't change the behavior of hashing at all, only statements that don't depend on each other were reordered.
It appears like the current order hasn't changed since its [original implementation from 2012](fada46c421 (diff-b751133c229259d7099bbbc7835324e5504b91ab1aded9464f0c48cd22e5e420R35)) which doesn't look like it was written with data dependencies in mind.
Running `./x bench library/core --stage 0 --test-args hash` before and after this change shows the following results:
Before:
```
benchmarks:
hash::sip::bench_bytes_4 7.20/iter +/- 0.70
hash::sip::bench_bytes_7 9.01/iter +/- 0.35
hash::sip::bench_bytes_8 8.12/iter +/- 0.10
hash::sip::bench_bytes_a_16 10.07/iter +/- 0.44
hash::sip::bench_bytes_b_32 13.46/iter +/- 0.71
hash::sip::bench_bytes_c_128 37.75/iter +/- 0.48
hash::sip::bench_long_str 121.18/iter +/- 3.01
hash::sip::bench_str_of_8_bytes 11.20/iter +/- 0.25
hash::sip::bench_str_over_8_bytes 11.20/iter +/- 0.26
hash::sip::bench_str_under_8_bytes 9.89/iter +/- 0.59
hash::sip::bench_u32 9.57/iter +/- 0.44
hash::sip::bench_u32_keyed 6.97/iter +/- 0.10
hash::sip::bench_u64 8.63/iter +/- 0.07
```
After:
```
benchmarks:
hash::sip::bench_bytes_4 6.64/iter +/- 0.14
hash::sip::bench_bytes_7 8.19/iter +/- 0.07
hash::sip::bench_bytes_8 8.59/iter +/- 0.68
hash::sip::bench_bytes_a_16 9.73/iter +/- 0.49
hash::sip::bench_bytes_b_32 12.70/iter +/- 0.06
hash::sip::bench_bytes_c_128 32.38/iter +/- 0.20
hash::sip::bench_long_str 102.99/iter +/- 0.82
hash::sip::bench_str_of_8_bytes 10.71/iter +/- 0.21
hash::sip::bench_str_over_8_bytes 11.73/iter +/- 0.17
hash::sip::bench_str_under_8_bytes 10.33/iter +/- 0.41
hash::sip::bench_u32 10.41/iter +/- 0.29
hash::sip::bench_u32_keyed 9.50/iter +/- 0.30
hash::sip::bench_u64 8.44/iter +/- 1.09
```
I ran this on my computer so there's some noise, but you can tell at least `bench_long_str` is significantly faster (~18%).
Also, I noticed the same compress function from the library is used in the compiler as well, so I took the liberty of copy-pasting this change to there as well.
Thanks `@semisol` for porting SipHash for another project which led me to notice this issue in Rust, and for helping investigate. <3
These tests have link errors on many platforms, so limit
them to only x86_64 linux for now. There are many other f16
non-doctests, so we don't need to run these particular ones
widely.
Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves#66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
Cleanup bootstrap check-cfg
This PR cleanup many custom `check-cfg` in bootstrap that have been accumulated over the years.
As well as updating some outdated comments.
In <https://github.com/rust-lang/rust/pull/127134>, the `Debug` impl for
`TypeId` was changed to print a single integer rather than a tuple.
Change this again to print as hex for more concise and consistent
formatting, as was suggested.
Result:
TypeId(0x1378bb1c0a0202683eb65e7c11f2e4d7)
small correction to fmt::Pointer impl
~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~
`expose_provenance` does not require `T: Sized`.
Print `TypeId` as a `u128` for `Debug`
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is represented as a `(u64, u64)`. This also made the debug implementation a lot larger, which is especially apparent with pretty formatting.
Change this to convert the inner value back to a `u128` and then print as a tuple struct to make this less noisy.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Small fixme in core now that split_first has no codegen issues
https://github.com/rust-lang/rust/issues/109328#issuecomment-1677366881
BTW, I have a crate implementing exactly this kind of an iterator: https://github.com/GrigorenkoPV/head-tail-iter and I was wondering if it would be worthwhile to try and make an ACP for it to get it included in std (or maybe itertools). My only doubt is that it kinda incentives writing O(n^2) algorithms and is not the hard to replace with a `while let` loop (just as in this PR).
Rollup of 9 pull requests
Successful merges:
- #123237 (Various rustc_codegen_ssa cleanups)
- #126960 (Improve error message in tidy)
- #127002 (Implement `x perf` as a separate tool)
- #127081 (Add a run-make test that LLD is not being used by default on the x64 beta/stable channel)
- #127106 (Improve unsafe extern blocks diagnostics)
- #127110 (Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.)
- #127114 (fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer)
- #127118 (Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.)
- #127122 (Remove uneccessary condition in `div_ceil`)
r? `@ghost`
`@rustbot` modify labels: rollup
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is
represented as a `(u64, u64)`. This also made the debug implementation a
lot larger, which is especially apparent with pretty formatting.
Make this less noisy by converting the inner value back to a `u128` then
printing as a tuple struct.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Remove uneccessary condition in `div_ceil`
Previously, `div_ceil` for unsigned integers had a `rhs > 0` for rounding. That condition however is always fulfilled, since `rhs == 0` would mean a division by zero earlier.
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes#119717Fixes#123664Fixes#124857Fixes#126148
