Refactor stack overflow handling
Currently, every platform must implement a `Guard` that protects a thread from stack overflow. However, UNIX is the only platform that actually does so. Windows has a different mechanism for detecting stack overflow, while the other platforms don't detect it at all. Also, the UNIX stack overflow handling is split between `sys::pal::unix::stack_overflow`, which implements the signal handler, and `sys::pal::unix::thread`, which detects/installs guard pages.
This PR cleans this by getting rid of `Guard` and unifying UNIX stack overflow handling inside `stack_overflow` (commit 1). Therefore we can get rid of `sys_common::thread_info`, which stores `Guard` and the current `Thread` handle and move the `thread::current` TLS variable into `thread` (commit 2).
The second commit is not strictly speaking necessary. To keep the implementation clean, I've included it here, but if it causes too much noise, I can split it out without any trouble.
Eliminate `UbChecks` for non-standard libraries
The purpose of this PR is to allow other passes to treat `UbChecks` as constants in MIR for optimization after #122629.
r? RalfJung
Soft-destabilize `RustcEncodable` & `RustcDecodable`, remove from prelude in next edition
cc rust-lang/libs-team#272
Any use of `RustcEncodable` and `RustcDecodable` now triggers a deny-by-default lint. The derives have been removed from the 2024 prelude. I specifically chose **not** to document this in the module-level documentation, as the presence in existing preludes is not documented (which I presume is intentional).
This does not implement the proposed change for `rustfix`, which I will be looking into shortly.
With regard to the items in the preludes being stable, this should not be an issue because #15702 has been resolved.
r? libs-api
Update `RwLock` deadlock example to not use shadowing
Tweak variable names in the deadlock example to remove any potential confusion that the behavior is somehow shadowing-related.
unix fs: Make hurd using explicit new rather than From
408c0ea216 ("unix time module now return result") dropped the From impl for SystemTime, breaking the hurd build (and probably the horizon build)
Fixes#123032
warning: casting raw pointers to the same type and constness is unnecessary (`*mut V` -> `*mut V`)
--> library\alloc\src\collections\btree\map\entry.rs:357:31
|
357 | let val_ptr = root.borrow_mut().push(self.key, value) as *mut V;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `root.borrow_mut().push
(self.key, value)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting to the same type is unnecessary (`usize` -> `usize`)
--> library\alloc\src\ffi\c_str.rs:411:56
|
411 | let slice = slice::from_raw_parts_mut(ptr, len as usize);
| ^^^^^^^^^^^^ help: try: `len`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting raw pointers to the same type and constness is unnecessary (`*mut T` -> `*mut T`)
--> library\alloc\src\slice.rs:516:25
|
516 | (buf.as_mut_ptr() as *mut T).add(buf.len()),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `buf.as_mut_ptr()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting raw pointers to the same type and constness is unnecessary (`*mut T` -> `*mut T`)
--> library\alloc\src\slice.rs:537:21
|
537 | (buf.as_mut_ptr() as *mut T).add(buf.len()),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `buf.as_mut_ptr()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting raw pointers to the same type and constness is unnecessary (`*const ()` -> `*const ()`)
--> library\alloc\src\task.rs:151:13
|
151 | waker as *const (),
| ^^^^^^^^^^^^^^^^^^ help: try: `waker`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting raw pointers to the same type and constness is unnecessary (`*const ()` -> `*const ()`)
--> library\alloc\src\task.rs:323:13
|
323 | waker as *const (),
| ^^^^^^^^^^^^^^^^^^ help: try: `waker`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting to the same type is unnecessary (`usize` -> `usize`)
--> library\std\src\sys_common\net.rs:110:21
|
110 | assert!(len as usize >= mem::size_of::<c::sockaddr_in>());
| ^^^^^^^^^^^^ help: try: `len`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
warning: casting to the same type is unnecessary (`usize` -> `usize`)
--> library\std\src\sys_common\net.rs:116:21
|
116 | assert!(len as usize >= mem::size_of::<c::sockaddr_in6>());
| ^^^^^^^^^^^^ help: try: `len`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_cast
std:🧵 refine available_parallelism for solaris/illumos.
Rather than the system-wide available cpus fallback solution, we fetch the cpus bound to the current process.
panic-in-panic-hook: formatting a message that's just a string is risk-free
This slightly improves the output in the 'panic while processing panic' case if the panic message does not involve any formatting. Follow-up to https://github.com/rust-lang/rust/pull/122930.
r? ``@Amanieu``
Relax SeqCst ordering in standard library.
Every single SeqCst in the standard library is unnecessary. In all cases, Relaxed or Release+Acquire was sufficient.
As I [wrote](https://marabos.nl/atomics/memory-ordering.html#common-misconceptions) in my book on atomics:
> [..] when reading code, SeqCst basically tells the reader: "this operation depends on the total order of every single SeqCst operation in the program," which is an incredibly far-reaching claim. The same code would likely be easier to review and verify if it used weaker memory ordering instead, if possible. For example, Release effectively tells the reader: "this relates to an acquire operation on the same variable," which involves far fewer considerations when forming an understanding of the code.
>
> It is advisable to see SeqCst as a warning sign. Seeing it in the wild often means that either something complicated is going on, or simply that the author did not take the time to analyze their memory ordering related assumptions, both of which are reasons for extra scrutiny.
r? ````@Amanieu```` ````@joboet````
Expose `ucred::peer_cred` on QNX targets to enable dist builds
After following https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html I attempted to run the following `x.py` command:
```bash
export build_env='
CC_aarch64-unknown-nto-qnx710=qcc
CFLAGS_aarch64-unknown-nto-qnx710=-Vgcc_ntoaarch64le_cxx
CXX_aarch64-unknown-nto-qnx710=qcc
AR_aarch64_unknown_nto_qnx710=ntoaarch64-ar
CC_x86_64-pc-nto-qnx710=qcc
CFLAGS_x86_64-pc-nto-qnx710=-Vgcc_ntox86_64_cxx
CXX_x86_64-pc-nto-qnx710=qcc
AR_x86_64_pc_nto_qnx710=ntox86_64-ar'
env $build_env ./x.py --stage 2 dist rust-std --target aarch64-unknown-nto-qnx710,x86_64-pc-nto-qnx710,x86_64-unknown-linux-gnu
```
The result was the following error:
```
Compiling object v0.32.2
Compiling std_detect v0.1.5 (/home/ana/git/rust-lang/rust/library/stdarch/crates/std_detect)
Compiling addr2line v0.21.0
error: function `peer_cred` is never used
--> library/std/src/os/unix/net/ucred.rs:89:12
|
89 | pub fn peer_cred(socket: &UnixStream) -> io::Result<UCred> {
| ^^^^^^^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
error: could not compile `std` (lib) due to 1 previous error
Build completed unsuccessfully in 0:06:25
```
I contacted `@flba-eb` and `@gh-tr` over email and we confirmed that `peer_cred` here should be flagged on `nto` targets. This should enable the clean `x.py --stage 2 dist rust-std` command on these platforms.
Use `UnsafeCell` for fast constant thread locals
This uses `UnsafeCell` instead of `static mut` for fast constant thread locals. This changes the type of the TLS shims to return `&UnsafeCell<T>` instead of `*mut T` which means they are always non-null so LLVM can optimize away the check for `Some` in `LocalKey::with` if `T` has no destructor.
LLVM is currently unable to do this optimization as we lose the fact that `__getit` always returns `Some` as it gets optimized to just returning the value of the TLS shim.
Bump windows-bindgen to 0.55.0
windows-bindgen is the crate used to generate std's Windows API bindings.
Not many changes for us, it's mostly just simplifying the generate code (e.g. no more `-> ()`). The one substantial change is some structs now use `i8` byte arrays instead of `u8`. However, this only impacts one test.
Mention labelled blocks in `break` docs
`break` doesn't require a loop, so note this in the docs. This is covered in the linked sections of the rust reference, but this page implied that `break` is only for loops.
`break` doesn't require a loop, so note this in the docs.
This is covered in the linked sections of the rust reference,
but this page implied that `break` is only for loops.
Cursor.rs documentation fix
Reason:
I've been learning Rust std library and got confused. Seek trait documentation clearly states that negative indexes will cause an error. And the code in the Cursor example uses negative index. I found myself trying to understand what am I missing until I've actually executed the code and got error. I decided to submit small fix to the documentation.
change std::process to drop supplementary groups based on CAP_SETGID
A trivial rebase of #95982
Should fix#39186 (from what I can tell)
Original description:
> Fixes#88716
>
> * Before this change, when a process was given a uid via `std::os::unix::process::CommandExt.uid`, there would be a `setgroups` call (when the process runs) to clear supplementary groups for the child **if the parent was root** (to remove potentially unwanted permissions).
> * After this change, supplementary groups are cleared if we have permission to do so, that is, if we have the CAP_SETGID capability.
>
> This new behavior was agreed upon in #88716 but there was a bit of uncertainty from `@Amanieu` here: [#88716 (comment)](https://github.com/rust-lang/rust/issues/88716#issuecomment-973366600)
>
> > I agree with this change, but is it really necessary to ignore an EPERM from setgroups? If you have permissions to change UID then you should also have permissions to change groups. I would feel more comfortable if we documented set_uid as requiring both UID and GID changing permissions.
>
> The way I've currently written it, we ignore an EPERM as that's what #88716 originally suggested. I'm not at all an expert in any of this so I'd appreciate feedback on whether that was the right way to go.
Avoid closing invalid handles
Documentation for [`HandleOrInvalid`] has this note:
> If holds a handle other than `INVALID_HANDLE_VALUE`, it will close the handle on drop.
Documentation for [`HandleOrNull`] has this note:
> If this holds a non-null handle, it will close the handle on drop.
Currently, both will call `CloseHandle` on their invalid handles as a result of using `OwnedHandle` internally, contradicting the above paragraphs. This PR adds destructors that match the documentation.
```@rustbot``` label A-io O-windows T-libs
[`HandleOrInvalid`]: https://doc.rust-lang.org/std/os/windows/io/struct.HandleOrInvalid.html
[`HandleOrNull`]: https://doc.rust-lang.org/std/os/windows/io/struct.HandleOrNull.html
unix time module now return result
First try to fix#108277 without break anything.
if anyone who read this know tips to be able to check compilation for different target I could use some help. So far I installed many target with rustup but `./x check --all-targets` doesn't seem to use them.
TODO:
- [x] better error
- [ ] test, how ?
`@rustbot` label -S-waiting-on-author +S-waiting-on-review
This commit provides a component model intrinsic in the standard library
by default on the `wasm32-wasip2` target. This intrinsic is not
required by the component model itself but is quite common to use, for
example it's needed if a wasm module receives a string or a list.
The intention of this commit is to provide an overridable definition in
the standard library through a weak definition of this function. That
means that downstream crates can provide their own customized and more
specific versions if they'd like, but the standard library's version
should suffice for general-purpose use.
The ordering of targets in `pal/mod.rs` did not end up using the wasip2
implementation, so after reordering that I've edited the implementation
to compile correctly.
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).
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)]`.
Given the nature of this code, I don't feel confident removing the field
so it is only marked as allow(dead_code).
std support for wasm32 panic=unwind
Tracking issue: #118168
This adds std support for `-Cpanic=unwind` on wasm, and with it slightly more fleshed out rustc support. Now, the stable default is still panic=abort without exception-handling, but if you `-Zbuild-std` with `RUSTFLAGS=-Cpanic=unwind`, you get wasm exception-handling try/catch blocks in the binary:
```rust
#[no_mangle]
pub fn foo_bar(x: bool) -> *mut u8 {
let s = Box::<str>::from("hello");
maybe_panic(x);
Box::into_raw(s).cast()
}
#[inline(never)]
#[no_mangle]
fn maybe_panic(x: bool) {
if x {
panic!("AAAAA");
}
}
```
```wat
;; snip...
(try $label$5
(do
(call $maybe_panic
(local.get $0)
)
(br $label$1)
)
(catch_all
(global.set $__stack_pointer
(local.get $1)
)
(call $__rust_dealloc
(local.get $2)
(i32.const 5)
(i32.const 1)
)
(rethrow $label$5)
)
)
;; snip...
```
std::threads: revisit stack address calculation on netbsd.
like older linux glibc versions, we need to get the guard size
and increasing the stack's bottom address accordingly.
Win10: Use `GetSystemTimePreciseAsFileTime` directly
On Windows 10 we can use `GetSystemTimePreciseAsFileTime` directly instead of lazy loading it (with a fallback).
Convert `Unix{Datagram,Stream}::{set_}passcred()` to per-OS traits
These methods are the pre-stabilized API for obtaining peer credentials from an `AF_UNIX` socket, part of the `unix_socket_ancillary_data` feature.
Their current behavior is to get/set one of the `SO_PASSCRED` (Linux), `LOCAL_CREDS_PERSISTENT` (FreeBSD), or `LOCAL_CREDS` (NetBSD) socket options. On other targets the `{set_}passcred()` methods do not exist.
There are two problems with this approach:
1. Having public methods only exist for certain targets isn't permitted in a stable `std` API.
2. These options have generally similar purposes, but they are non-POSIX and their details can differ in subtle and surprising ways (such as whether they continue to be set after the next call to `recvmsg()`).
Splitting into OS-specific extension traits is the preferred solution to both problems.
io::Read trait: make it more clear when we are adressing implementations vs callers
Inspired by [this](https://github.com/rust-lang/rust/issues/72186#issuecomment-1987076295) comment.
For some reason we only have that `buf` warning in `read` and `read_exact`, even though it affects a bunch of other functions of this trait as well. It doesn't seem worth copy-pasting the same text everywhere though so I did not change this.
Dynamically size sigaltstk in std
On modern Linux with Intel AMX and 1KiB matrices,
Arm SVE with potentially 2KiB vectors,
and RISCV Vectors with up to 16KiB vectors,
we must handle dynamic signal stack sizes.
We can do so unconditionally by using getauxval,
but assuming it may return 0 as an answer,
thus falling back to the old constant if needed.
Fixes https://github.com/rust-lang/rust/issues/107795
Implement junction_point
Implements https://github.com/rust-lang/rust/issues/121709
We already had a private implementation that we use for tests so we could just make that public. Except it was very hacky as it was only ever intended for use in testing. I've made an improved version that at least handles path conversion correctly and has less need for things like the `Align8` hack. There's still room for further improvement though.
impl From<TryReserveError> for io::Error
There's an obvious mapping between these two errors, and it makes I/O code less noisy.
I've chosen to use simple `ErrorKind::OutOfMemory` `io::Error`, without keeping `TryReserveError` for the `source()`, because:
* It matches current uses in libstd,
* `ErrorData::Custom` allocates, which is a risky proposition for handling OOM errors specifically.
* Currently `TryReserveError` has no public fields/methods, so it's usefulness is limited. How allocators should report errors, especially custom and verbose ones is still an open question.
Just in case I've added note in the doccomment that this may change.
The compiler forced me to declare stability of this impl. I think this implementation is simple enough that it doesn't need full-blown stabilization period, and I've marked it for the next release, but of course I can adjust the attribute if needed.
fix `close_read_wakes_up` test
On windows, `shutdown` does not interrupt `read`, even though we document that it does (see https://github.com/rust-lang/rust/issues/121594).
The `close_read_wakes_up` test has a race condition and only passes on windows if the `shutdown` happens before the `read`. This PR ignores the test on windows adds a sleep to make it more likely that the `read` happens before the `shutdown` and the test actually tests what it is supposed to test on other platforms.
I'm submitting this before any docs changes, so that we can find out on what platforms `shutdown` actually works as documented.
r? `@ChrisDenton`
Specifically, when an override doesn't just forward to an inner type,
document the behavior and that it's preferred over simply assigning
a clone of source. Also, change instances where the second parameter is
"other" to "source".
Fix quadratic behavior of repeated vectored writes
Some implementations of `Write::write_vectored` in the standard library (`BufWriter`, `LineWriter`, `Stdout`, `Stderr`) check all buffers to calculate the total length. This is O(n) over the number of buffers.
It's common that only a limited number of buffers is written at a time (e.g. 1024 for `writev(2)`). `write_vectored_all` will then call `write_vectored` repeatedly, leading to a runtime of O(n²) over the number of buffers.
This fix is to only calculate as much as needed if it's needed.
Here's a test program:
```rust
#![feature(write_all_vectored)]
use std::fs::File;
use std::io::{BufWriter, IoSlice, Write};
use std::time::Instant;
fn main() {
let buf = vec![b'\0'; 100_000_000];
let mut slices: Vec<IoSlice<'_>> = buf.chunks(100).map(IoSlice::new).collect();
let mut writer = BufWriter::new(File::create("/dev/null").unwrap());
let start = Instant::now();
write_smart(&slices, &mut writer);
println!("write_smart(): {:?}", start.elapsed());
let start = Instant::now();
writer.write_all_vectored(&mut slices).unwrap();
println!("write_all_vectored(): {:?}", start.elapsed());
}
fn write_smart(mut slices: &[IoSlice<'_>], writer: &mut impl Write) {
while !slices.is_empty() {
// Only try to write as many slices as can be written
let res = writer
.write_vectored(slices.get(..1024).unwrap_or(slices))
.unwrap();
slices = &slices[(res / 100)..];
}
}
```
Before this change:
```
write_smart(): 6.666952ms
write_all_vectored(): 498.437092ms
```
After this change:
```
write_smart(): 6.377158ms
write_all_vectored(): 6.923412ms
```
`LineWriter` (and by extension `Stdout`) isn't fully repaired by this because it looks for newlines. I could open an issue for that after this is merged, I think it's fixable but not trivially.
Improve std::fs::read_to_string example
Resolves [#118621](https://github.com/rust-lang/rust/issues/118621)
For the original code to succeed it requires address.txt to contain a socketaddress, however it is much easier to follow if this is just any strong - eg address could be a street address or just text.
Also changed the variable name from "foo" to something more meaningful as cargo clippy warns you against using foo as a placeholder.
```
$ cat main.rs
use std::fs;
use std::error::Error;
fn main() -> Result<(), Box<dyn Error>> {
let addr: String = fs::read_to_string("address.txt")?.parse()?;
println!("{}", addr);
Ok(())
}
$ cat address.txt
123 rusty lane
san francisco 94999
$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `/home/haydon/workspace/rust-test-pr/tester/target/debug/tester`
123 rusty lane
san francisco 94999
```
Make `std::os::unix::ucred` module private
Tracking issue: #42839
Currently, this unstable module exists: [`std::os::unix::ucred`](https://doc.rust-lang.org/stable/std/os/unix/ucred/index.html).
All it does is provide `UCred` (which is also available from `std::os::unix::net`), `impl_*` (which is probably a mishap and should be private) and `peer_cred` (which is undocumented but has a documented counterpart at `std::os::unix::net::UnixStream::peer_cred`).
This PR makes the entire `ucred` module private and moves it into `net`, because that's where it is used.
I hope it's fine to simply remove it without a deprecation phase. Otherwise, I can add back a deprecated reexport module `std::os::unix::ucred`.
`@rustbot` label: -T-libs +T-libs-api
Rollup of 9 pull requests
Successful merges:
- #121958 (Fix redundant import errors for preload extern crate)
- #121976 (Add an option to have an external download/bootstrap cache)
- #122022 (loongarch: add frecipe and relax target feature)
- #122026 (Do not try to format removed files)
- #122027 (Uplift some feeding out of `associated_type_for_impl_trait_in_impl` and into queries)
- #122063 (Make the lowering of `thir::ExprKind::If` easier to follow)
- #122074 (Add missing PartialOrd trait implementation doc for array)
- #122082 (remove outdated fixme comment)
- #122091 (Note why we're using a new thread in `test_get_os_named_thread`)
r? `@ghost`
`@rustbot` modify labels: rollup
On modern Linux with Intel AMX and 1KiB matrices,
Arm SVE with potentially 2KiB vectors,
and RISCV Vectors with up to 16KiB vectors,
we must handle dynamic signal stack sizes.
We can do so unconditionally by using getauxval,
but assuming it may return 0 as an answer,
thus falling back to the old constant if needed.
If it's obvious from the actual syscall results themselves that the
syscall is supported or unsupported, don't do an extra syscall with an
invalid file descriptor.
CC #122052
This test won't work on windows 7, as the Thread::set_name function is
not implemented there (win7 does not provide a documented mechanism to
set thread names).
Some implementations of `Write::write_vectored` in the standard
library (`BufWriter`, `LineWriter`, `Stdout`, `Stderr`) check all
buffers to calculate the total length. This is O(n) over the number of
buffers.
It's common that only a limited number of buffers is written at a
time (e.g. 1024 for `writev(2)`). `write_vectored_all` will then call
`write_vectored` repeatedly, leading to a runtime of O(n²) over the
number of buffers.
The fix is to only calculate as much as needed if it's needed.
Cleanup windows `abort_internal`
As the comments on the functions say, we define abort in both in panic_abort and in libstd. This PR makes the two implementation (mostly) the same.
Additionally it:
* uses `options(noreturn)` on the asm instead of using `core::intrinsics::unreachable`.
* removed unnecessary allow lints
* added `FAST_FAIL_FATAL_APP_EXIT` to our generated Windows API bindings instead of defining it manually (std only)
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`.
fix typo in documentation for std::fs::Permissions
Please check and re-check this PR carefully to see if I got this right.
But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
The new interface has some similarities to Linux system call
getdents64. The system call reads several dirent64 structures.
At the end of each dirent64 is stored the name of the file.
The length of file name is implictly part of dirent64 because
d_reclen contains size of dirent64 plus the length of the file
name.
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
Use volatile access instead of `#[used]` for `on_tls_callback`
The first commit adds a volatile load of `p_thread_callback` when registering a dtor so that the compiler knows if the callback is used or not. I don't believe the added volatile instruction is otherwise significant in the context. In my testing using the volatile load allowed the compiler to correctly reason about whether `on_tls_callback` is used or not, allowing it to be omitted entirely in some cases. Admittedly it usually is used due to `Thread` but that can be avoided (e.g. in DLLs or with custom entry points that avoid the offending APIs). Ideally this would be something the compiler could help a bit more with so we didn't have to use tricks like `#[used]` or volatile. But alas.
I also used this as an opportunity to clean up the `unused` lints which I don't think serve a purpose any more.
The second commit removes the volatile load of `_tls_used` with `#cfg[target_thread_local]` because `#[thread_local]` already implies it. And if it ever didn't then `#[thread_local]` would be broken when there aren't any dtors.
add platform-specific function to get the error number for HermitOS
Extending `std` to get the last error number for HermitOS.
HermitOS is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Implement unwind safety for Condvar on all platforms
Closes#118009
This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.
In #118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](https://github.com/rust-lang/rust/issues/121690#issuecomment-1968298470) I copy the stability information from the previous unwind safety implementations.
Increase visibility of `join_path` and `split_paths`
Add some crosslinking among `std::env` pages to make it easier to discover `join_paths` and `split_paths`. Also add aliases to help anyone searching for `PATH`.
Closes#118009
This commit adds unwind safety to Condvar. Previously, only select
platforms implemented unwind safety through auto traits. Known by this
committer: Linux was unwind safe, but Mac and Windows are not before
this change.
Extending `std` to get the last error number for HermitOS.
HermitOS is a tier 3 platform and this PR changes only files,
wich are related to the tier 3 platform.
Add a new `wasm32-wasi-preview2` target
This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).
There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.
Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
os::net: expanding TcpStreamExt for Linux with `tcp_deferaccept`.
allows for socket to process only when there is data to process, the option sets a number of seconds until the data is ready.
rename 'try' intrinsic to 'catch_unwind'
The intrinsic has nothing to do with `try` blocks, and corresponds to the stable `catch_unwind` function, so this makes a lot more sense IMO.
Also rename Miri's special function while we are at it, to reflect the level of abstraction it works on: it's an unwinding mechanism, on which Rust implements panics.
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
Add manual Sync impl for ReentrantLockGuard
Fixes: #125526
Tracking Issue: #121440
this impl is even shown in the summary in the tracking issue, but apparently was forgotten in the actual implementation
Rollup of 6 pull requests
Successful merges:
- #125263 (rust-lld: fallback to rustc's sysroot if there's no path to the linker in the target sysroot)
- #125345 (rustc_codegen_llvm: add support for writing summary bitcode)
- #125362 (Actually use TAIT instead of emulating it)
- #125412 (Don't suggest adding the unexpected cfgs to the build-script it-self)
- #125445 (Migrate `run-make/rustdoc-with-short-out-dir-option` to `rmake.rs`)
- #125452 (Cleanup check-cfg handling in core and std)
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup check-cfg handling in core and std
Follow-up to https://github.com/rust-lang/rust/pull/125296 where we:
- expect any feature cfg in std, due to `#[path]` imports
- move some check-cfg args inside the `build.rs` as per Cargo recommendation
- and replace the fake Cargo feature `"restricted-std"` by the custom cfg `restricted_std`
Fixes https://github.com/rust-lang/rust/pull/125296#issuecomment-2127009301
r? `@bjorn3` (maybe, feel free to re-roll)
Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS
Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance).
The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute).
That we've been overly cautious here has also been noted by `@thomcc` in https://github.com/rust-lang/rust/pull/117910#issuecomment-1903372350.
r? `@workingjubilee`
`@rustbot` label O-apple
switch to the default implementation of `write_vectored`
HermitOS doesn't support write_vectored and switch to the default implementation of `write_vectored`.
Fix `read_exact` and `read_buf_exact` for `&[u8]` and `io:Cursor`
- Drain after `read_exact` and `read_buf_exact`
- Append to cursor in `read_buf_exact`
revise the interpretation of ReadDir for HermitOS
HermitOS supports getdents64. As under Linux, the dirent64 entry `d_off` is not longer used, because its definition is not clear. Instead of `d_off` the entry `d_reclen` is used to determine the end of the dirent64 entry.
In addition, take up `@workingjubilee` suggestion from the discussions in rust-lang/rust#115984 to increase the readability.
Hermit is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Update documentation related to the recent cmd.exe fix
Fix some grammar nits, change `bat` (extension) -> `batch` (file), and make line wrapping more consistent.
If we're comfortable using `_NSGetEnviron` from `crt_externs.h`, there shouldn't be an issue with using these either, and then we can merge with the macOS implementation.
This also fixes two test cases on Mac Catalyst:
- `tests/ui/command/command-argv0.rs`, maybe because `[[NSProcessInfo processInfo] arguments]` somehow converts the name of the first argument?
- `tests/ui/env-funky-keys.rs` since we no longer link to Foundation.
