Currently, the `std::os::unix::net::UnixStream` docs do not specify that
the SOCK_CLOEXEC flag is set on new sockets. This commit adds a note
clarifying that, in line with the note abuot the `MSG_NOSIGNAL` flag.
Fix compile issue in Vita libstd
Unfortunately it looks like the Vita libc does not support
the "utimensat" function, which is needed for setting file times.
To fix the build, this commit marks Vita as unsupported for the
function that sets the file times.
std: remove unsupported pipe module from VEXos pal
rust-lang/rust#146794 moved `pipe` implementations out of PAL and into a toplevel `sys` module. While most targets supporting libstd were updated, the PR did not remove the old module from the `vexos` PAL, causing builds to fail on the `armv7a-vex-v5` target.
<img width="2258" height="322" alt="image" src="https://github.com/user-attachments/assets/3bdb83f9-e577-4795-9d20-0ae4ab5d505c" />
This PR removes the old module path in the PAL and allows `vexos` targets to fall back to the `unsupported` implementation in sys/pipe.
std: Use `usleep` temporarily on WASI targets
This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.
Closesrust-lang/rust#150290
Unfortunately it looks like the Vita libc does not support
the "utimensat" function, which is needed for setting file times.
To fix the build, this commit marks Vita as unsupported for the
function that sets the file times.
Signed-off-by: John Nunley <dev@notgull.net>
This fixes some fallout from 147572 where the `thread::sleep` function
is is broken on `wasm32-wasip2` after that PR. The cause for this is a
broken implementation of `nanosleep` in wasi-libc itself which is being
fixed in WebAssembly/wasi-libc/696. Similar to 149999 this avoids the
problematic function for now while the wasi-libc changes take some time
to propagate into a wasi-sdk release.
Expand `str_as_str` to more types
Tracking issue: rust-lang/rust#130366
ACP: https://github.com/rust-lang/libs-team/issues/643
This PR expands `str_from_str` feature and adds analogous methods to more types. Namely:
- `&CStr`
- `&[T]`, `&mut [T]`
- `&OsStr`
- `&Path`
- `&ByteStr`, `&mut ByteStr` (tracking issue: rust-lang/rust#134915) (technically was not part of ACP)
This caused several performance regressions because of existing code
which uses `Read::read` and therefore requires full buffer
initialization. This is particularly a problem when the same buffer is
re-used for multiple read calls since this means it needs to be fully
re-initialized each time.
There is still some benefit to landing the API changes, but we will have
to add private APIs so that the existing infrastructure can
track and avoid redundant initialization.
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`
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.
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
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
Ivan