std: introduce path normalize methods at top of `std::path`
Closesrust-lang/rust#142931
Mention other methods that call `conponents` and `canonicalize` that fully normalize path. And fix two typo.
r? libs
std: Don't panic when removing a nonexistent UEFI var
`std::env::remove_var` does not say that deleting a nonexistent variable is an error (and at least on Linux, it indeed does not cause an error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the edk2 implementation delegates to the UEFI runtime `SetVariable` function, which returns `EFI_NOT_FOUND` when trying to delete a nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat it as success.
CC @Ayush1325
`std::env::remove_var` does not say that deleting a nonexistent variable
is an error (and at least on Linux, it indeed does not cause an
error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the
edk2 implementation delegates to the UEFI runtime `SetVariable`
function, which returns `EFI_NOT_FOUND` when trying to delete a
nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat
it as success.
RwLock: refine documentation to emphasize non-reentrancy guarantees
This addresses the need for clarification brought up in rust-lang/rust#149693. Specifically, it notes that some implementations may choose to panic if they detect deadlock situations during recursive locking attempts for both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock. (as demonstrated in the very same documentation a few paragraphs above)
* Improve documentation regarding the possibility of panics during recursive read or write lock attempts.
Issues: https://github.com/rust-lang/rust/issues/149693
Update wasi-sdk used in CI/releases
This is similar to prior updates such as rust-lang/rust#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.
* In rust-lang/rust#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang/rust#149864, rust-lang/rust#150291, and rust-lang/rust#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.
Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
This is similar to prior updates such as 149037 in that this is just
updating a URL. This update though has some technical updates
accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this
target, even for startup. This means that the final binary no longer
has an "adapter" which can help making instantiation of a component a
bit more lean.
* In 147572 libstd was updated to use wasi-libc more often on the
`wasm32-wasip2` target. This uncovered a number of bugs in
wasi-libc such as 149864, 150291, and 151016. These are all fixed in
wasi-sdk-30 so the workarounds in the standard library are all
removed.
Overall this is not expected to have any sort of major impact on users
of WASI targets. Instead it's expected to be a normal routine update to
keep the wheels greased and oiled.
library/std: Rename `ON_BROKEN_PIPE_FLAG_USED` to `ON_BROKEN_PIPE_USED`
This commit is a pure internal rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the current compiler flag `-Zon-broken-pipe=...` and for the upcoming [Externally Implementable Item `#[std::io::on_broken_pipe]`](https://github.com/rust-lang/rust/pull/150591) PR. This makes the diff of that PR smaller.
The local variable name `sigpipe_attr_specified` comes from way back when the feature was controlled with an `fn main()` attribute called `#[unix_sigpipe = "..."]`. Rename that too.
This commmit is a pure rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the
compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the flag
`-Zon-broken-pipe=...` and for the upcoming Externally Implementable
Item `#[std::io::on_broken_pipe]`. This makes the diff of that PR
smaller.
The local variable name `sigpipe_attr_specified` comes from way back
when the feature was controlled with an `fn main()` attribute called
`#[unix_sigpipe = "..."]`. Rename that too.
Fix set_times_nofollow for directory on windows
Fix issue from:
https://github.com/rust-lang/rust/issues/147455#issuecomment-3841311858
old code `opts.write(true)` on Windows requests `GENERIC_WRITE` access, replace with `opts.access_mode(c::FILE_WRITE_ATTRIBUTES)` to get minimal permission.
r? @joshtriplett
This addresses the need for clarification brought up in an issue.
Specifically, it notes that some implementations may choose to panic if
they detect deadlock situations during recursive locking attempts for
both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be
held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock.
(as demonstrated in the very same documentation a few paragraphs
above)
* Improve documentation regarding the possibility of panics during
recursive read or write lock attempts.
Issues: Ambiguity in RwLock documentation about multiple read() calls...
Signed-off-by: Henner Zeller <h.zeller@acm.org>
Fix uninitialized UEFI globals in tests
Export globals via a `doc(hidden)` module. In test code, use the globals from `realstd` so that they are properly initialized.
CC @Ayush1325
This commit introduces initial, unstable support for Unix domain sockets
(UDS) on Windows, behind the `windows_unix_domain_sockets` feature gate
Added types:
- `std::os::windows::net::SocketAddr`: represents a UDS address with support
for pathname addresses (abstract and unnamed are parsed but not yet fully
supported).
- `std::os::windows::net::UnixListener`: server-side UDS listener.
- `std::os::windows::net::UnixStream`: client/server stream for UDS.
Key features:
- Binding and connecting using filesystem paths.
- Basic I/O via `Read`/`Write`.
- Address querying (`local_addr`, `peer_addr`).
- Non-blocking mode, timeouts, and socket duplication.
- Includes basic test coverage for smoke, echo, path length, and bind reuse.
thread::scope: document how join interacts with TLS destructors
Fixes https://github.com/rust-lang/rust/issues/116237 by documenting the current behavior regarding thread-local destructors as intended. (I'm not stoked about this, but documenting it is better than leaving it unclear.)
This also adds documentation for explicit `join` calls (both for scoped and regular threads), saying that those *will* wait for TLS destructors. That reflects my understanding of the current implementation, which calls `join` on the native thread handle. Are we okay with guaranteeing that? I think we should, so people have at least some chance of implementing "wait for all destructors" manually. This fixes https://github.com/rust-lang/rust/issues/127571.
Cc @rust-lang/libs-api
compiler-builtins: Remove the no-f16-f128 feature
This option was used to gate `f16` and `f128` when support across backends and targets was inconsistent. We now have the rustc builtin cfg `target_has_reliable{f16,f128}` which has taken over this usecase. Remove no-f16-f128 since it is now unused and redundant.
- PATHS_SEP is defined as global const since I will implement
split_paths in the future.
- Tested using OVMF using QEMU.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Last on the list: Hermit. Since I anticipate that Hermit will share the UNIX
implementation in the future, I've left `Timespec` in the PAL to maintain a
similar structure. Also, I noticed that some public `Instant` methods were
redefined on the internal `Instant`. But the networking code can just use the
public `Instant`, so I've removed them.
WASI and TEEOS share the UNIX implementation. Since `Timespec` lives in the
PAL, this means that the `#[path]` imports of `unix/time.rs` still remain for
these two, unfortunately. Maybe we'll solve that in the future by always
including the UNIX PAL for these remotely UNIXy platforms. But that's a story
for another time...
Now for UNIX: `Timespec` is also used for things like futex or `Condvar`
timeouts, so it stays in the PAL along with some related definitions.
Everything else is `SystemTime`- and `Instant`-specific, and is thus moved to
`sys::time`.
Windows has a similar problem as UEFI: some internals are also used for
implementing other things. Thus I've left everything except for the actual
`Instant` and `SystemTime` implementations inside the PAL.
I've also taken the liberty of improving the code clarity a bit: there were a
number of manual `SystemTime` conversions (including one that masked an `i64`
to 32-bits before casting to `u32`, yikes) that now just call `from_intervals`.
Also, defining a `PerformanceCounterInstant` just to convert it to a regular
`Instant` immediately doesn't really make sense to me. I've thus changed the
`perf_counter` module to contain only free functions that wrap system
functionality. The actual conversion now happens in `Instant::now`.
Next up: UEFI. Unfortunately the time conversion internals are also required by
the filesystem code, so I've left them in the PAL. The `Instant` internals
however are only used for the `Instant` implementation, so I've moved them to
`sys` (for now).
On SOLID, the conversion functions are also used to implement helpers for
timeout conversion, so these stay in the PAL. The `Instant` (µITRON) and
`SystemTime` (SOLID-specific) implementations are merged into one. While it was
nice to have the µITRON parts in a separate module, there really isn't a need
for this currently, as there is no other µITRON target. Let's not worry about
this until such a target gets added...
Note that I've extracted the `get_tim` call from `Instant` into a wrapper
function in the PAL to avoid the need to make the inner `Instant` field public
for use in the PAL.
Now that the `unsupported` module exists, we can use it for VEX. VEX actually
supports `Instant` though, so the implementation-select needs to combine that
with the `unsupported` module.
Let's start with the easy ones:
* Motor just reexports its platform library
* The SGX code is just a trivial move
* Trusty, WASM and ZKVM are unsupported, this is very trivial. And we can get
rid of some `#[path = ...]`s, yay!
remove `#[deprecated]` from unstable & internal `SipHasher13` and `24` types
These types are unstable and `doc(hidden)` (under the internal feature `hashmap_internals`). Deprecating them only adds noise (`#[allow(deprecated)]`) to all places where they are used, so this PR removes the deprecation attributes from them.
It also includes a few other small cleanups in separate commits, including one I overlooked in rust-lang/rust#151228.
Fix(lib/win/thread): Ensure `Sleep`'s usage passes over the requested duration under Win7
Fixesrust-lang/rust#149935. See the added comment for more details.
This makes the concerned test now reproducibly pass, for us at least. Also, testing this separately revealed successful: see the issue.
@rustbot label C-bug I-flaky-test O-windows-7 T-libs A-time A-thread
