| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=Noratrieb
wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next
When upgrading [Zed](https://github.com/zed-industries/zed/pull/19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773844e7ebf05ccb827c17b7ad9eb28aa295
As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773844e7ebf05ccb827c17b7ad9eb28aa295 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82.
This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
|
|
thread::available_parallelism for wasm32-wasip1-threads
The target has limited POSIX support and provides the `libc::sysconf` function which allows querying the number of available CPUs.
|
|
|
|
|
|
|
|
The target has limited POSIX support and provides the sysconf
function which allows querying the number of available
CPUs.
|
|
|
|
When upgrading [Zed](https://github.com/zed-industries/zed/pull/19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82
Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773844e7ebf05ccb827c17b7ad9eb28aa295
As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81;
the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously.
With 1.82 and 736f773844e7ebf05ccb827c17b7ad9eb28aa295 it is no longer the case, thus we're seeing the hang.
This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer.
Previously we'd only terminate the loop if readdir returned 0.
|
|
Add as_slice/into_slice for IoSlice/IoSliceMut.
ACP: https://github.com/rust-lang/libs-team/issues/93
Tracking issue: #132818
Based on a623c5233ae7f6b540e5c00f2be02f40b33b0793 (CC `@mpdn)` and #111277 (CC `@Lucretiel).`
Closes: #124659
Tracking Issue: TODO
try-job: test-various
try-job: dist-various-1
try-job: dist-various-2
r? libs
|
|
Co-authored-by: Mike Pedersen <mike@mikepedersen.dk>
Co-authored-by: Nathan West <Lucretiel@gmail.com>
|
|
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and
unlock() to File gated behind the file_lock feature flag
|
|
Implements the ACP https://github.com/rust-lang/libs-team/issues/393.
|
|
|
|
|
|
This commit fixes an assert in the WASI-specific implementation of
thread sleep to ensure that sleeping for a very large period of time
blocks instead of panicking. This can come up when testing programs that
sleep "forever", for example.
|
|
|
|
fix: fs::remove_dir_all: treat internal ENOENT as success
fixes #127576
try-job: test-various
|
|
fixes #127576
windows implementation still needs some work
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
|
|
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
|
|
|
|
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
|
|
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
@rustbot label +A-thread-locals
|
|
|
|
Prevent copy-paste errors from producing new starved-for-resources
threaded platforms by raising `DEFAULT_MIN_STACK_SIZE` from 4096 bytes
to at least 64KiB.
Two platforms "affected" by this have no actual threads:
- UEFI
- "unsupported"
Platforms that this actually affects:
- wasm32-wasi with "atomics" enabled
- wasm32-wasi-p1-threads
Two exceptions:
- SGX: a "secure code execution" platform, stays at 4096B
- TEEOS: also a "secure code execution" platform, stays at 8192B
I believe either of these may have sufficiently "interesting" semantics
around threads, or significant external library support. Either would
mean making any choices here for them is suspect.
|
|
Allow calling these functions without `unsafe` blocks in editions up
until 2021, but don't trigger the `unused_unsafe` lint for `unsafe`
blocks containing these functions.
Fixes #27970.
Fixes #90308.
CC #124866.
|
|
|
|
This reverts #121666 due to #123495
|
|
|
|
Replace visibility test with reachability test in dead code detection
Fixes https://github.com/rust-lang/rust/issues/119545
Also included is a fix for an error now flagged by the lint
|
|
|
|
The dead_code lint was previously eroneously missing this dead code.
Since this lint bug has been fixed, the unused field need
to be removed or marked as `#[allow(dead_code)]`.
These structures API is common to all platforms so the code cannot be
removed and is hence marked allow(dead_code).
|
|
Use the OS thread name by default if `THREAD_INFO` has not been initialized
Currently if `THREAD_INFO` hasn't been initialized then the name will be set to `None`. This PR changes it to use the OS thread name by default. This mostly affects foreign threads at the moment but we could expand this to make more use of the OS thread name in the future.
Note: I've only implemented `Thread::get_name` for windows, linux and macos (and macos adjacent) targets. The rest just return `None`.
|
|
|
|
Delete architecture-specific memchr code in std::sys
Currently all architecture-specific memchr code is only used in `std::io`. Most of the actual `memchr` capacity exposed to the user through the slice API is instead implemented in `core::slice::memchr`.
Hence this commit deletes `memchr` from `std::sys[_common]` and replace calls to it by calls to `core::slice::memchr` functions. This deletes `(r)memchr` from the list of symbols linked to libc.
The interest of putting architecture specific code back in core is linked to the discussion to be had in #113654
|
|
Signed-off-by: Ryan Levick <me@ryanlevick.com>
|
|
|
|
Currently all architecture-specific memchr code is only used in
`std::io`. Most of the actual `memchr` capacity exposed to the user
through the slice API is instead implemented in core::slice::memchr.
Hence this commit deletes memchr from std::sys[_common] and replace
calls to it by calls to core::slice::memchr functions. This deletes
(r)memchr from the list of symbols linked to libc.
|
|
Move locks to `sys`
Part of #117276.
r? `@ChrisDenton`
|
|
|
|
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
|
|
|
|
|
|
|
|
|
|
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
|
|
Revert outdated version of "Add the wasm32-wasi-preview2 target"
An outdated version of #119616 was merged in rollup #120309.
This reverts those changes to enable #119616 to “retain the intended diff” after a rebase.
```@rylev``` has agreed that this would be the cleanest approach with respect to the history.
Unblocks #119616.
r? ```@petrochenkov``` or compiler or libs
|
