Always use WaitOnAddress on Win10+
`WaitOnAddress` and `WakeByAddressSingle` are always available since Windows 8 so they can now be used without needing to delay load. I've also moved the Windows 7 thread parking fallbacks into a separate sub-module.
Fix sgx unit test compilation
Fixes a compilation error:
```
error[E0583]: file not found for module `tests`
--> library/std/src/sys/locks/rwlock/sgx.rs:2:1
|
2 | mod tests;
| ^^^^^^^^^^
|
= help: to create the module `tests`, create file "library/std/src/sys/locks/rwlock/sgx/tests.rs" or "library/std/src/sys/locks/rwlock/sgx/tests/mod.rs"
= note: if there is a `mod tests` elsewhere in the crate already, import it with `use crate::...` instead
For more information about this error, try `rustc --explain E0583`.
error: could not compile `std` (lib test) due to 1 previous error`
```
When running command:
```
`TF_BUILD=True RUST_TEST_THREADS=1 ./x.py test --stage 1 "library/std" tests/assembly tests/run-make --target=x86_64-fortanix-unknown-sgx --no-doc --exclude src/tools/linkchecker --exclude src/tools/rust-demangler --no-fail-fast 2>&1
```
The fix is done by moving a file to the location suggested by the compiler.
The issue was introduced by PR: https://github.com/rust-lang/rust/pull/121177
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`.
ACP: https://github.com/rust-lang/libs-team/issues/260
Tracking issue: https://github.com/rust-lang/rust/issues/117108
<details> <summary> (Outdated) </summary>
`MutexState`/`RwLockState` structs
~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields.
</details>
The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments.
Unresolved question: Are more tests needed?
Fix incorrect doc of ScopedJoinHandle::is_finished
Fixes the explanation how to use `is_finished` to achieve a non-blocking join. The updated version matches the documentation of the non-scoped JoinHandle::is_finished.
Fixes the explanation how to use is_finished to achieve a non-blocking
join. The updated version matches the documentation of the non-scoped
JoinHandle::is_finished.
Help with common API confusion, like asking for `push` when the data structure really has `append`.
```
error[E0599]: no method named `size` found for struct `Vec<{integer}>` in the current scope
--> $DIR/rustc_confusables_std_cases.rs:17:7
|
LL | x.size();
| ^^^^
|
help: you might have meant to use `len`
|
LL | x.len();
| ~~~
help: there is a method with a similar name
|
LL | x.resize();
| ~~~~~~
```
#59450
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.
Specialize some methods of `io::Chain`
This PR specializes the implementation of some methods of `io::Chain`, which could bring performance improvements when using it.
Reduce monomorphisation bloat in small_c_string
This is a code path usually next to an FFI call, so taking the `dyn` slowdown for the 1159 llvm-line (fat lto, codegen-units 1, release build) drop in my testing program [t2fanrd](https://github.com/GnomedDev/t2fanrd) is worth it imo.
Move `OsStr::slice_encoded_bytes` validation to platform modules
This delegates OS string slicing (`OsStr::slice_encoded_bytes`) validation to the underlying platform implementation. For now that results in increased performance and better error messages on Windows without any changes to semantics. In the future we may want to provide different semantics for different platforms.
The existing implementation is still used on Unix and most other platforms and is now optimized a little better.
Tracking issue: https://github.com/rust-lang/rust/issues/118485
cc `@epage,` `@BurntSushi`
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
Use a hardcoded constant instead of calling OpenProcessToken.
Now that Win 7 support is dropped, we can resurrect #90144.
GetCurrentProcessToken is defined in processthreadsapi.h as:
FORCEINLINE
HANDLE
GetCurrentProcessToken (
VOID
)
{
return (HANDLE)(LONG_PTR) -4;
}
Since it's very unlikely that this constant will ever change, let's just use it instead of making calls to get the same information.
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.
Now that Win 7 support is dropped, we can resurrect #90144.
GetCurrentProcessToken is defined in processthreadsapi.h as:
FORCEINLINE
HANDLE
GetCurrentProcessToken (
VOID
)
{
return (HANDLE)(LONG_PTR) -4;
}
Since it's very unlikely that this constant will ever change, let's just use it instead of making calls to get the same information.
std::thread update freebsd stack guard handling.
up to now, it had been assumed the stack guard setting default is not touched in the field but some user might just want to disable it or increase it. checking it once at runtime should be enough.
Make contributing to windows bindings easier
This PR does three things:
- Automatically sorts bindings so contributors don't have to. I should have done this to begin with but was lazy.
- Renames `windows_sys.lst` to `bindings.txt`. This [matches the windows-rs repository](8e71051ea8/crates/tools/sys/bindings.txt) (and repos that copy it). I believe consistency with other projects helps get people orientated.
- Adds a `README.md` file explaining what this is about and how to add bindings. This has the benefit of being directly editable and it's rendered when viewed online. Also people are understandably jumping right into the `windows_sys.rs` file via ripgrep or github search and so missing that it's generated. A `README.md` alongside it is at least slightly more obvious in that case. There is still a small note at the top of `windows_sys` in case people do read from the beginning.
None of this has any impact on the actual code generated. It's purely to make the new contributors workflow a bit nicer.
Rollup of 13 pull requests
Successful merges:
- #116387 (Additional doc links and explanation of `Wake`.)
- #118738 (Netbsd10 update)
- #118890 (Clarify the lifetimes of allocations returned by the `Allocator` trait)
- #120498 (Uplift `TypeVisitableExt` into `rustc_type_ir`)
- #120530 (Be less confident when `dyn` suggestion is not checked for object safety)
- #120915 (Fix suggestion span for `?Sized` when param type has default)
- #121015 (Optimize `delayed_bug` handling.)
- #121024 (implement `Default` for `AsciiChar`)
- #121039 (Correctly compute adjustment casts in GVN)
- #121045 (Fix two UI tests with incorrect directive / invalid revision)
- #121049 (Do not point at `#[allow(_)]` as the reason for compat lint triggering)
- #121071 (Use fewer delayed bugs.)
- #121073 (Fix typos in `OneLock` doc)
r? `@ghost`
`@rustbot` modify labels: rollup
Optimize away poison guards when std is built with panic=abort
> **Note**: To take advantage of this PR, you will have to use `-Zbuild-std` or build your own toolchain. rustup toolchains always link to a libstd that was compiled with `panic=unwind`, since it's compatible with `panic=abort` code.
When std is compiled with `panic=abort` we can remove a lot of the poison machinery from the locks. This changes the `Flag` and `Guard` types to be ZSTs. It also adds an uninhabited member to `PoisonError` so the compiler knows it can optimize away the `Result::Err` paths, and make `LockResult<T>` layout-equivalent to `T`.
### Is this a breaking change?
`PoisonError::new` now panics if invoked from a libstd built with `panic="abort"` (or any non-`unwind` strategy). It is unclear to me whether to consider this a breaking change.
In order to encounter this behavior, **both of the following must be true**:
#### Using a libstd with `panic="abort"`
This is pretty uncommon. We don't build libstd with that in rustup, except in (Tier 2-3) platforms that do not support unwinding, **most notably wasm**.
Most people who do this are using cargo's `-Z build-std` feature, which is unstable.
`panic="abort"` is not a supported option in Rust's build system. It is possible to configure it using `CARGO_TARGET_xxx_RUSTFLAGS`, but I believe this only works on **non-host** platforms.
#### Creating `PoisonError` manually
This is also unlikely. The only common use case I can think of is in tests, and you can't run tests with `panic="abort"` without the unstable `-Z panic_abort_tests` flag.
It's possible that someone is implementing their own locks using std's `PoisonError` **and** defining "thread failure" to mean something other than "panic". If this is the case then we would break their code if it was used with a `panic="abort"` libstd. The locking crates I know of don't replicate std's poison API, but I haven't done much research into this yet.
I've touched on a fair number of considerations here. Which ones do people consider relevant?
`compile_fail` should only be used when the code is meant to show
what *not* to do. In other words, there should be a fundamental flaw
in the code. However, in this case, the example is just incomplete,
so we should use `ignore` to avoid confusing readers.
Implement sys/thread for UEFI
Since UEFI has no concept of threads, most of this module can be ignored. However, implementing parts that make sense.
- Implement sleep
- Implement available_parallelism
Replace pthread `RwLock` with custom implementation
This is one of the last items in #93740. I'm doing `RwLock` first because it is more self-contained and has less tradeoffs to make. The motivation is explained in the documentation, but in short: the pthread rwlock is slow and buggy and `std` can do much better. I considered implementing a parking lot, as was discussed in the tracking issue, but settled for the queue-based version because writing self-balancing binary trees is not fun in Rust...
This is a rather complex change, so I have added quite a bit of documentation to help explain it. Please point out any part that could be explained better.
~~The read performance is really good, I'm getting 4x the throughput of the pthread version and about the same performance as usync/parking_lot on an Apple M1 Max in the usync benchmark suite, but the write performance still falls way behind what usync and parking_lot achieve. I tried using a separate queue lock like what usync uses, but that didn't help. I'll try to investigate further in the future, but I wanted to get some eyes on this first.~~ [Resolved](https://github.com/rust-lang/rust/pull/110211#issuecomment-1513682336)
r? `@m-ou-se`
CC `@kprotty`
Make cmath.rs a single file
It makes sense to have this all in one file. There's essentially only one target that has missing symbols and that's easy enough to handle inline.
Note that the Windows definitions used to use `c_float` and `c_double` whereas the other platforms all used `f32` and `f64`. They've now been made consistent. However, `c_float` and `c_double` have the expected definitions on all Windows platforms we support.
Since UEFI has no concept of threads, most of this module can be
ignored. However, implementing parts that make sense.
- Implement sleep
- Implement available_parallelism
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Introducing a new config for this purpose as NetBSD 9 or 8 will be still around
for a good while. For now, we re finally enabling sys::unix::rand::getrandom.
Add support for custom JSON targets when using build-std.
Currently, when building with `build-std`, some library build scripts check properties of the target by inspecting the target triple at `env::TARGET`, which is simply set to the filename of the JSON file when using JSON target files.
This patch alters these build scripts to use `env::CARGO_CFG_*` to fetch target information instead, allowing JSON target files describing platforms without `restricted_std` to build correctly when using `-Z build-std`. There are some weak assertions here (for example, `nintendo && newlib`), however this seems at least a marginal improvement on the existing solution.
Fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/60.
up to now, it had been assumed the stack guard setting default is not
touched in the field but some user might just want to disable it or
increase it. checking it once at runtime should be enough.
Always check the result of `pthread_mutex_lock`
Fixes#120147.
Instead of manually adding a list of "good" platforms, I've simply made the check unconditional. pthread's mutex is already quite slow on most platforms, so one single well-predictable branch shouldn't hurt performance too much.
Currently, when building with `build-std`, some library build scripts
check properties of the target by inspecting the target triple at
`env::TARGET`, which is simply set to the filename of the JSON file
when using JSON target files.
This patch alters these build scripts to use `env::CARGO_CFG_*` to
fetch target information instead, allowing JSON target files
describing platforms without `restricted_std` to build correctly when
using `-Z build-std`.
Fixes wg-cargo-std-aware/#60.
fix#120603 by adding a check in default_read_buf
Fixes#120603 by checking the returned read n is in-bounds of the cursor.
Interestingly, I noticed that `BorrowedBuf` side-steps this issue by using checked accesses. Maybe this can be switched to unchecked to mirror what BufReader does bf3c6c5bed/library/core/src/io/borrowed_buf.rs (L95)
Store SHOULD_CAPTURE as AtomicU8
`BacktraceStyle` easily fits into a u8, so `SHOULD_CAPTURE`, which is just `Atomic<Option<BacktraceStyle>>`, should be stored as `AtomicU8`
std: thread_local::register_dtor fix proposal for FreeBSD.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage. using instead home made TLS destructor handler `register_dtor_fallback`.
close#120413
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
std: Update documentation of seek_write on Windows
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states:
> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.
This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
Handle out of memory errors in io:Read::read_to_end()
#116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi`
----
I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large.
Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone.
While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662).
I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait.
I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail.
This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
Adjust Behaviour of `read_dir` and `ReadDir` in Windows Implementation: Check Whether Path to Search In Exists
This pull request changes the `read_dir` function's and the `ReadDir` structure's internal implementations for the Windows operating system to make its behaviour more accurate.
It should be noted that `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function when *no matching files can be found*, not necessarily that the path to search in does not exist in the first place. Therefore, directly returning the "The system cannot find the file specified." may not be accurate.
An extra check for whether the path to search in exists is added, returning a constructed `ReadDir` iterator with its handle being an `INVALID_HANDLE_VALUE` returned by the `FindFirstFileW` function if `ERROR_FILE_NOT_FOUND` is indeed the last OS error. The `ReadDir` implementation for the Windows operating system is correspondingly updated to always return `None` if the handle it has is an `INVALID_HANDLE_VALUE` which can only be the case if and only if specifically constructed by the `read_dir` function in the aforementioned conditions.
It should also be noted that `FindFirstFileW` would have returned `ERROR_PATH_NOT_FOUND` if the path to search in does not exist in the first place.
Presumably fixes#120040.
