Due to an erroneous overflow threshold, `expm1f` was incorrectly
returning `inf` for inputs in the range `[88.72169, 88.72283]`. This
additionally caused `sinhf` to return `NaN` for inputs in that range.
The bug was ported from the original in musl, which has since been fixed
in [1].
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=964104f9f0e056cf58d9defa0b716d7756f040f6
Avoid using `Ord::clamp` in the `f16`-specific part of the generic
`scalbn`.
It turned out to be redundant anyway, as both callsites follow a pattern
like
```
if n < negative_val {
let foo = (n + positive_val).clamp(negative_val, positive_val);
}
```
and `n < negative_val < 0` implies `n + positive_val < positive_val`.
Fixes: rust-lang/compiler-builtins#1046
std: io: error: Add comment for UEFI unpacked repr use
The following commit adds the comment explaining the rational why UEFI uses unpacked representation on 64-bit platforms as opposed to bit-packed representation used in all other 64-bit platforms.
r? `@bjorn3`
custom `VaList` layout for Hexagon
I noticed while browsing LLVM source that we use an incorrect `VaList` definition for the musl hexagon target.
relevant links
- 0cdc1b6dd4/clang/include/clang/Basic/TargetInfo.h (L333)
- 0cdc1b6dd4/clang/lib/CodeGen/Targets/Hexagon.cpp (L407-L417)
cc target maintainer `@androm3da` can you confirm that this looks OK? In particular the `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute is used to simulate pointer decay (like if the struct were wrapped in a 1-element array in C). The clang comment suggests that the Tag is wrapped in such a single-element array, but I haven't actually been able to confirm it.
For stabilizing `c_variadic` (on the hexagon targets) we will also need a custom `va_arg` implementation to mirror the one in `clang` in [va_arg.rs](https://github.com/rust-lang/rust/blob/main/compiler/rustc_codegen_llvm/src/va_arg.rs). Would you be able to contribute one?
r? `@workingjubilee`
The following commit adds the comment explaining the rational why UEFI
uses unpacked representation on 64-bit platforms as opposed to bit-packed
representation used in all other 64-bit platforms.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
document that mpmc channels deliver an item to (at most) one receiver
Tiny documentation change related to mpmc (tracking issue rust-lang/rust#126840).
This PR is meant to supersede rust-lang/rust#140158 due to it's inactivity. It is essentially the same addition structured a little differently.
std: small `sys` refactor
Part of rust-lang/rust#117276
The large number of files changed just results from the need to update a lot of imports. Actually this PR only:
* combines the two definitions of `RawOsError` in `sys::pal` into one in `sys::io`
* moves `FULL_BACKTRACE_DEFAULT` from `sys::pal` to `sys::backtrace`
* moves the `FromInner`/`IntoInner`/... traits into `sys` (in preparation for removing `sys_common` entirely)
Link POSIX instead of Linux manual for Instant
This commit changes the links in the source code that link to a platform specific implementation of the POSIX interface of `clock_gettime`, despite the respective areas in the code being specifically UNIX system agnostic, thereby making it more reasonable to link the POSIX specific document.
test: update duplicate many_digits test to use f64 instead of f32
Replace the f32 test case with an f64 equivalent to improve coverage for parsing large digit counts in double-precision floating-point conversion. Specifically, this PR updates the `many_digits` test in `library/coretests/tests/num/dec2flt/parse.rs` to test f64 (double-precision) parsing instead of f32 (single-precision).
The test verifies that decimal strings with an excessive number of digits (beyond `Decimal::MAX_DIGITS`) are parsed correctly, ensuring proper truncation of insignificant digits. Previously, the same test was repeated twice (see comment https://github.com/rust-lang/rust/pull/86761#issuecomment-3623334228 by `@Viatorus).`
## Changes
- Replaced the duplicated f32 test case with an equivalent f64 test case.
- Updated the expected bit pattern and input string to a very long decimal with many trailing zeros, testing the limits of f64 precision.
replace addr_of_mut with &raw mut in maybeuninit docs
In the docs for `addr_of_mut` it says that the macro is "soft-deprecated" so maybe the std docs should stop recommending it.
I searched for other places where this is used, but didn't find any in public stable documentation.
std: Don't use `linkat` on the `wasm32-wasi*` targets
This commit is a follow-up to rust-lang/rust#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
std: reorganize pipe implementations
Currently, there are two distinct types called `AnonPipe` in `std`:
* The one used to implement `io::pipe` (in `sys::anonymous_pipe`)
* The one used to implement `Stdin`/`Stdout`/`Stderr` (in `sys::pal::pipe`)
On Windows, these actually have different semantics, as one of the handles returned by the `sys::pal::pipe` version is opened for asynchronous operation in order to support `read2`, whereas the `sys::anonymous_pipe` version does not do so. Thus the naming is extremely confusing.
To fix this, this PR renames the `sys::anonymous_pipe` version of `AnonPipe` to simply `Pipe`, whereas the `sys::pal::pipe` version is now called `ChildPipe`. Additionally,
* `sys::anonymous_pipe` is now also just called `sys::pipe`.
* On Windows, `sys::pal::pipe` has been moved to `sys::process` and is now called `sys::process::child_pipe`.
* On non-Windows platforms, pipe creation is now exclusively handled by `sys::pipe` and `ChildPipe` is defined as a type alias to `Pipe` within `sys::process`.
And lastly, the `read2` function (originally in `sys::pal::pipe`) is now called `read_output` and defined by `sys::process`, as (at least on Windows) it is only usable with `ChildPipe`.
Includes rust-lang/rust#146639 for convenience.
This commit changes the links in the source code that link to a platform
specific implementation of the POSIX interface of `clock_gettime`,
despite the respective areas in the code being specifically UNIX system
agnostic, thereby making it more reasonable to link the POSIX specific
document.
Add SystemTime::{MIN, MAX}
Accepted ACP: <https://github.com/rust-lang/libs-team/issues/692>
Tracking Issue: <https://github.com/rust-lang/rust/issues/149067>
---
This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform.
Technically, this value is already obtainable during runtime with the following algorithm:
Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None.
Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever.
Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail.
In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`.
However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction.
With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time.
This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably:
* rust-lang/rust#100141
* rust-lang/rust#133525
* rust-lang/rust#105762
* rust-lang/rust#71224
* rust-lang/rust#45448
* rust-lang/rust#52555
Constify `DropGuard::dismiss` and trait impls
Feature: `drop_guard` (rust-lang/rust#144426), `const_convert` (rust-lang/rust#143773), `const_drop_guard` (no tracking issue yet)
Constifies `DropGuard::dismiss` and trait impls.
I reused `const_convert` (rust-lang/rust#143773) for the `Deref*` impls.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
The Windows implementation of `SystemTime::checked_sub` contains a bug,
namely that it does not return `None` on values below 1601.
This bug stems from the fact that internally, the time gets converted to
an i64, with zero representing the anchor in 1601. Of course,
performing checked subtraction on a signed integer generally works fine.
However, the resulting value delivers undefined behavior on Windows
systems.
To mitigate this issue, we try to convert the resulting i64 to an u64
because a negative value should obviously fail there.
There is a slight edge case when adding and subtracting a `Duration`
from a `SystemTime`, namely when the duration itself is finer/smaller
than the time precision on the operating systems.
On most (if not all non-Windows) operating systems, the precision of
`Duration` aligns with the `SystemTime`, both being one nanosecond.
However, on Windows, this time precision is 100ns, meaning that adding
or subtracting a `Duration` whose value is `< Duration::new(0, 100)`
will result in that method behaving like an addition/subtracting of
`Duration::ZERO`, due to the `Duration` getting rounded-down to the zero
value.
This commit introduces two new constants to SystemTime: `MIN` and `MAX`,
whose value represent the maximum values for the respective data type,
depending upon the platform.
Technically, this value is already obtainable during runtime with the
following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add`
(or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it
returns None. Mathematically speaking, this algorithm will terminate
after a finite amount of steps, yet it is impractical to run it, as it
takes practically forever.
Besides, this commit also adds a unit test. Concrete implementation
depending upon the platform is done in later commits.
In the future, the hope of the authors lies within the creation of a
`SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar
to the functions already present in `std::time::Duration`. However, for
those, these constants are crucially required, thereby this should be
seen as the initial step towards this direction.
Below are platform specifc notes:
# Hermit
The HermitOS implementation is more or less identitcal to the Unix one.
# sgx
The implementation uses a `Duration` to store the Unix time, thereby
implying `Duration::ZERO` and `Duration::MAX` as the limits.
# solid
The implementation uses a `time_t` to store the system time within a
single value (i.e. no dual secs/nanosecs handling), thereby implying its
`::MIN` and `::MAX` values as the respective boundaries.
# UEFI
UEFI has a weird way to store times, i.e. a very complicated struct.
The standard proclaims "1900-01-01T00:00:00+0000" to be the lowest
possible value and `MAX_UEFI_TIME` is already present for the upper
limit.
# Windows
Windows is weird. The Win32 documentation makes no statement on a
maximum value here. Next to this, there are two conflicting types:
`SYSTEMTIME` and `FILETIME`. Rust's Standard Library uses `FILETIME`,
whose limit will (probably) be `i64::MAX` packed into two integers.
However, `SYSTEMTIME` has a lower-limit.
# xous
It is similar to sgx in the sense of using a `Duration`.
# unsupported
Unsupported platforms store a `SystemTime` in a `Duration`, just like
sgx, thereby implying `Duration::ZERO` and `Duration::MAX` as the
respective limits.
Port `doc` attributes to new attribute API
Part of https://github.com/rust-lang/rust/issues/131229.
This PR ports the `doc` attributes to the new attribute API. However, there are things that will need to be fixed in a follow-up:
* Some part of `cfg_old.rs` are likely unused now, so they should be removed.
* Not all error/lints are emitted at the same time anymore, making them kinda less useful considering that you need to run and fix rustc/rustdoc multiple times to get through all of them.
* For coherency with the other attribute errors, I didn't modify the default output too much, meaning that we have some new messages now. I'll likely come back to that to check if the previous ones were better in a case-by-case approach.
* `doc(test(attr(...)))` is handled in a horrifying manner currently. Until we can handle it correctly with the `Attribute` system, it'll remain that thing we're all very ashamed of. 😈
* A type in rustdoc got its size increased, I'll check the impact on performance. But in any case, I plan to improve it in a follow-up so should be "ok".
* Because of error reporting, some fields of `Doc` are suboptimal, like `inline` which instead of being an `Option` is a `ThinVec` because we report the error later on. Part of the things I'm not super happy about but can be postponed to future me.
* In `src/librustdoc/clean/cfg.rs`, the `pub(crate) fn parse(cfg: &MetaItemInner) -> Result<Cfg, InvalidCfgError> {` function should be removed once `cfg_trace` has been ported to new `cfg` API.
* Size of type `DocFragment` went from 32 to 48. Would be nice to get it back to 32.
* ``malformed `doc` attribute input`` wasn't meant for so many candidates, should be improved.
* See how many of the checks in `check_attr` we can move to attribute parsing
* Port target checking to be in the attribute parser completely
* Fix target checking for `doc(alias)` on fields & patterns
And finally, once this PR is merged, I plan to finally stabilize `doc_cfg` feature. :)
cc `@jdonszelmann`
r? `@JonathanBrouwer`
This commit is a follow-up to 147572 and the issue reported at the end
of that PR where the `std::fs::hard_link` function is broken after that
PR landed. The true culprit and bug here is fixed in
WebAssembly/wasi-libc/690 but until that's released in a wasi-sdk
version it should be reasonable, on WASI, to skip the `linkat`
function.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#148052 (Stabilize `const_mul_add`)
- rust-lang/rust#149386 (Display funding link in the github overview)
- rust-lang/rust#149489 (Experimentally add *heterogeneous* `try` blocks)
- rust-lang/rust#149764 (Make `--print=backend-has-zstd` work by default on any backend)
- rust-lang/rust#149838 (Build auxiliary in pretty tests)
- rust-lang/rust#149839 (Use `PointeeSized` bound for `TrivialClone` impls)
- rust-lang/rust#149846 (Statically require links to an issue or the edition guide for all FCWs)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `PointeeSized` bound for `TrivialClone` impls
These `TrivialClone` impls previously had `?Sized` bounds, which are different from the `PointeeSized` bounds on the corresponding `Clone` and `Copy` impls. So, I've changed the `?Sized` bounds into `PointeeSized` bounds.
This mistake was made presumably because the `TrivialClone` PR (https://github.com/rust-lang/rust/pull/135634) was opened in Jan 2025, but merged in Nov 2025. During that time, the sized hierachy PR (https://github.com/rust-lang/rust/pull/137944) was opened in Mar 2025, and merged in Jun 2025. The `TrivialClone` PR was not updated to account for the sized hierachy changes.
r? `@joboet`
