Rollup of 6 pull requests
Successful merges:
- #113939 (open pidfd in child process and send to the parent via SOCK_SEQPACKET+CMSG)
- #114548 (Migrate a trait selection error to use diagnostic translation)
- #114606 (fix: not insert missing lifetime for `ConstParamTy`)
- #114634 (Mention riscv64-linux-android support in Android documentation)
- #114638 (Remove old RPITIT tests (revisions were removed))
- #114641 (Rename copying `ascii::Char` methods from `as_` to `to_`)
r? `@ghost`
`@rustbot` modify labels: rollup
open pidfd in child process and send to the parent via SOCK_SEQPACKET+CMSG
This avoids using `clone3` when a pidfd is requested while still getting it in a 100% race-free manner by passing it up from the child process.
This should solve most concerns in #82971
Make ExitStatus implement Default
And, necessarily, make it inhabited even on platforms without processes.
I noticed while preparing https://github.com/rust-lang/rfcs/pull/3362 that there was no way for anyone to construct an `ExitStatus`.
This would be insta-stable so needs an FCP.
unix/kernel_copy.rs: copy_file_range_candidate allows empty output files
This is for https://github.com/rust-lang/rust/issues/114341
The `meta.len() > 0` condition here is intended for inputs only, ie. when input is in the `/proc` filesystem as documented.
That inaccurately included empty output files which are then shunted to the sendfile() routine leading to higher than nescessary IO util in some cases, specifically with CoW filesystems like btrfs.
Simply, determine what is input or output given the passed boolean.
This is for https://github.com/rust-lang/rust/issues/114341
The `meta.len() > 0` condition here is intended for inputs only,
ie. when input is in the `/proc` filesystem as documented.
That inaccurately included empty output files which are then shunted to
the sendfile() routine leading to higher than nescessary IO util in some
cases, specifically with CoW filesystems like btrfs.
Further, `NoneObtained` is not relevant in this context, so remove it.
Simply, determine what is input or output given the passed enum Unit.
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
`wait_while` takes care of spurious wake-ups in centralized place,
reducing chances for mistakes and potential future optimizations
(who knows, maybe in future there will be no spurious wake-ups? :)
WASI threads, implementation of wasm32-wasi-preview1-threads target
This PR adds a target proposed in https://github.com/rust-lang/compiler-team/issues/574 by `@abrown` and implementation of `std:🧵:spawn` for the target `wasm32-wasi-preview1-threads`
### Tier 3 Target Policy
As tier 3 targets, the new targets are required to adhere to [the tier 3 target policy](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy) requirements. This section quotes each requirement in entirety and describes how they are met.
> - A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/pull/112922/files#diff-a48ee9d94f13e12be24eadd08eb47b479c153c340eeea4ef22276d876dfd4f3e).
> - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
> - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
The target is using the same name for $ARCH=wasm32 and $OS=wasi as existing Rust targets. The suffix `preview1` introduced to accurately set expectations because eventually this target will be deprecated and follows [MCP 607](https://github.com/rust-lang/compiler-team/issues/607). The suffix `threads` indicates that it’s an extension that enables threads to the existing target and it follows [MCP 574](https://github.com/rust-lang/compiler-team/issues/574) which describes the rationale behind introducing a separate target.
> - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
> - The target must not introduce license incompatibilities.
> - Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
> - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
This PR does not introduce any new dependency.
The new target doesn’t support building host tools.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The full standard library is available for this target as it’s an extension to an existing target that has already supported it.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Only manual test running is supported at the moment with some tweaks in the test runner codebase. For build and running tests see [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/pull/112922/files#diff-a48ee9d94f13e12be24eadd08eb47b479c153c340eeea4ef22276d876dfd4f3e).
> - Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> - This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
> - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> - Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
> - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
I acknowledge these requirements and intend to ensure they are met.
Change default panic handler message format.
This changes the default panic hook's message format from:
```
thread '{thread}' panicked at '{message}', {location}
```
to
```
thread '{thread}' panicked at {location}:
{message}
```
This puts the message on its own line without surrounding quotes, making it easiser to read. For example:
Before:
```
thread 'main' panicked at 'env variable `IMPORTANT_PATH` should be set by `wrapper_script.sh`', src/main.rs:4:6
```
After:
```
thread 'main' panicked at src/main.rs:4:6:
env variable `IMPORTANT_PATH` should be set by `wrapper_script.sh`
```
---
See this PR by `@nyurik,` which does that for only multi-line messages (specifically because of `assert_eq`): https://github.com/rust-lang/rust/pull/111071
This is the change that does that for *all* panic messages.
Re-export core::ffi::FromBytesUntilNulError in std::ffi
Like the other CStr and CString error types, make a re-export for std::ffi::FromBytesUntilNulError.
This seems to have slipped through the cracks in the cstr_from_bytes_until_nul implementation and core_c_str migration.
Tracking Issue: #95027
Make `Debug` representations of `[Lazy, Once]*[Cell, Lock]` consistent with `Mutex` and `RwLock`
`Mutex` prints `<locked>` as a field value when its inner value cannot be accessed, but the lazy types print a fixed string like "`OnceCell(Uninit)`". This could cause confusion if the inner type is a unit type named `Uninit` and does not respect the pretty-printing flag. With this change, the format message is now "`OnceCell(<uninit>)`", consistent with `Mutex`.
Use `LazyLock` to lazily resolve backtraces
By using TAIT to name the initializing closure, `LazyLock` can be used to replace the current `LazilyResolvedCapture`.
merge functionality of `io::Sink` into `io::Empty`
Many times, there is a need for a simple dummy `io::Read`er + `io::Write`r, but currently the only options are `io::Empty` and `io::Sink` respectively. Having both of their functionality together requires writing your own boilerplate for something that makes sense to have in the standard library. This PR adds the functionality of `io::Sink` to `io::Empty`, making `io::Empty` be able to perform the tasks of both of the previous structs. (This idea was first mentioned in #24235)
Note: I also updated some doc comments in `io::utils` in this pull request to fix inconsistencies between `io::Sink` and `io::Empty`.
API Change Proposal: https://github.com/rust-lang/libs-team/issues/49
Fix issue_15149 test for the SGX target
PR https://github.com/rust-lang/rust/pull/112390 moved tests to std. Unfortunately, this caused the `issue_15149` test to be enabled for the SGX target. This is incorrect as the SGX target does not support the `env::current_exe()` call.
Fix switch-stdout test for none unix/windows platforms
PR #112390 moved tests to std. Unfortunately, there is a typo which causes issues on platforms other than unix and windows.
Move two tests from `tests/ui/std` to `library/std/tests`
Hi, there,
This pull request comes from this issue (#99417), sorry I made some mistakes creating the pull request, it's my first one.
Make std tests pass on newer Android
Newer versions of Android forbid the creation of hardlinks as well as Unix domain sockets in the /data filesystem via SELinux rules, which causes several tests depending on this behavior to fail. So let's skip these tests on Android if we see an EACCES from one of these syscalls. To achieve this, introduce a macro with the horrible name of or_panic_or_skip_on_android_eacces (better suggestions welcome) which skips (returns from) the test if an EACCES return value is seen on Android.
Add `x86_64-unikraft-linux-musl` target
This introduces `x86_64-unikraft-linux-musl` as the first Rust target for the [Unikraft] Unikernel Development Kit.
[Unikraft]: https://unikraft.org/
Unikraft imitates Linux and uses musl as libc.
It is extremely configurable, and does not even provide a `poll` implementation or a network stack, unless enabled by the end user who compiles the application.
Our approach for integrating the build process with `rustc` is to hide the build process as well as the actual final linking step behind a linker-shim (`kraftld`, see https://github.com/unikraft/kraftkit/issues/612).
## Tier 3 target policy
> - A tier 3 target must have a designated developer or developers (the "target
> maintainers") on record to be CCed when issues arise regarding the target.
> (The mechanism to track and CC such developers may evolve over time.)
I will be the target maintainer.
> - Targets must use naming consistent with any existing targets; for instance, a
> target for the same CPU or OS as an existing Rust target should use the same
> name for that CPU or OS. Targets should normally use the same names and
> naming conventions as used elsewhere in the broader ecosystem beyond Rust
> (such as in other toolchains), unless they have a very good reason to
> diverge. Changing the name of a target can be highly disruptive, especially
> once the target reaches a higher tier, so getting the name right is important
> even for a tier 3 target.
> - Target names should not introduce undue confusion or ambiguity unless
> absolutely necessary to maintain ecosystem compatibility. For example, if
> the name of the target makes people extremely likely to form incorrect
> beliefs about what it targets, the name should be changed or augmented to
> disambiguate it.
> - If possible, use only letters, numbers, dashes and underscores for the name.
> Periods (`.`) are known to cause issues in Cargo.
The target name `x86_64-unikraft-linux-musl` was derived from `x86_64-unknown-linux-musl`, setting Unikraft as vendor.
Unikraft exactly imitates Linux + musl.
> - Tier 3 targets may have unusual requirements to build or use, but must not
> create legal issues or impose onerous legal terms for the Rust project or for
> Rust developers or users.
> - The target must not introduce license incompatibilities.
> - Anything added to the Rust repository must be under the standard Rust
> license (`MIT OR Apache-2.0`).
> - The target must not cause the Rust tools or libraries built for any other
> host (even when supporting cross-compilation to the target) to depend
> on any new dependency less permissive than the Rust licensing policy. This
> applies whether the dependency is a Rust crate that would require adding
> new license exceptions (as specified by the `tidy` tool in the
> rust-lang/rust repository), or whether the dependency is a native library
> or binary. In other words, the introduction of the target must not cause a
> user installing or running a version of Rust or the Rust tools to be
> subject to any new license requirements.
> - Compiling, linking, and emitting functional binaries, libraries, or other
> code for the target (whether hosted on the target itself or cross-compiling
> from another target) must not depend on proprietary (non-FOSS) libraries.
> Host tools built for the target itself may depend on the ordinary runtime
> libraries supplied by the platform and commonly used by other applications
> built for the target, but those libraries must not be required for code
> generation for the target; cross-compilation to the target must not require
> such libraries at all. For instance, `rustc` built for the target may
> depend on a common proprietary C runtime library or console output library,
> but must not depend on a proprietary code generation library or code
> optimization library. Rust's license permits such combinations, but the
> Rust project has no interest in maintaining such combinations within the
> scope of Rust itself, even at tier 3.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
> legal/licensing terms include but are *not* limited to: non-disclosure
> requirements, non-compete requirements, contributor license agreements
> (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
> requirements conditional on the employer or employment of any particular
> Rust developers, revocable terms, any requirements that create liability
> for the Rust project or its developers or users, or any requirements that
> adversely affect the livelihood or prospects of the Rust project or its
> developers or users.
No dependencies were added to Rust.
Requirements for linking are [Unikraft] and [KraftKit] (both BSD-3-Clause), but none of these are added to Rust.
[KraftKit]: https://github.com/unikraft/kraftkit
> - Neither this policy nor any decisions made regarding targets shall create any
> binding agreement or estoppel by any party. If any member of an approving
> Rust team serves as one of the maintainers of a target, or has any legal or
> employment requirement (explicit or implicit) that might affect their
> decisions regarding a target, they must recuse themselves from any approval
> decisions regarding the target's tier status, though they may otherwise
> participate in discussions.
> - This requirement does not prevent part or all of this policy from being
> cited in an explicit contract or work agreement (e.g. to implement or
> maintain support for a target). This requirement exists to ensure that a
> developer or team responsible for reviewing and approving a target does not
> face any legal threats or obligations that would prevent them from freely
> exercising their judgment in such approval, even if such judgment involves
> subjective matters or goes beyond the letter of these requirements.
Understood.
I am not a member of a Rust team.
> - Tier 3 targets should attempt to implement as much of the standard libraries
> as possible and appropriate (`core` for most targets, `alloc` for targets
> that can support dynamic memory allocation, `std` for targets with an
> operating system or equivalent layer of system-provided functionality), but
> may leave some code unimplemented (either unavailable or stubbed out as
> appropriate), whether because the target makes it impossible to implement or
> challenging to implement. The authors of pull requests are not obligated to
> avoid calling any portions of the standard library on the basis of a tier 3
> target not implementing those portions.
Understood.
`std` is supported.
> - The target must provide documentation for the Rust community explaining how
> to build for the target, using cross-compilation if possible. If the target
> supports running binaries, or running tests (even if they do not pass), the
> documentation must explain how to run such binaries or tests for the target,
> using emulation if possible or dedicated hardware if necessary.
Building is described in the platform support doc.
It will be updated once proper `kraftld` support has landed.
> - Tier 3 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to maintain the target. In particular,
> do not post comments (automated or manual) on a PR that derail or suggest a
> block on the PR based on a tier 3 target. Do not send automated messages or
> notifications (via any medium, including via ``@`)` to a PR author or others
> involved with a PR regarding a tier 3 target, unless they have opted into
> such messages.
> - Backlinks such as those generated by the issue/PR tracker when linking to
> an issue or PR are not considered a violation of this policy, within
> reason. However, such messages (even on a separate repository) must not
> generate notifications to anyone involved with a PR who has not requested
> such notifications.
Understood.
> - Patches adding or updating tier 3 targets must not break any existing tier 2
> or tier 1 target, and must not knowingly break another tier 3 target without
> approval of either the compiler team or the maintainers of the other tier 3
> target.
> - In particular, this may come up when working on closely related targets,
> such as variations of the same architecture with different features. Avoid
> introducing unconditional uses of features that another variation of the
> target may not have; use conditional compilation or runtime detection, as
> appropriate, to let each target run code supported by that target.
I don't think this PR breaks anything.
r? compiler-team
fix docs & example for `std::os::unix::prelude::FileExt::write_at`
Changelog:
* used `File::create` instead of `File::read` to get a writeable file
* explicity mentioned the bug with `pwrite64` in docs
Unfortunately, I don't think that there is really much we can do about this since the feature has already been stabilised.
We could potentially add a clippy lint warning people on Linux that using `write_at` with the `O_APPEND` flag does not exhibit the behaviour that they would have assumed.
fixes#113627
Allow limited access to `OsString` bytes
This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString` as suggested in feedback from `os_str_bytes` crate in #111544.
std: remove an allocation in `Path::with_extension`
`Path::with_extension` used to reallocate (and copy) paths twice per call, now it does it once, by checking the size of the previous and new extensions it's possible to call `PathBuf::with_capacity` and pass the exact capacity required.
This also reduces the memory consumption of the path returned from `Path::with_extension` by using exact capacity instead of using amortized exponential growth.
Update documentation for std::process::Command's new method
In the current documentation, it's not specified that when creating a Command, the .exe extension can be omitted for Windows executables. However, for other types of executable files like .bat or .cmd, the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()` succeeds on my machine while `Command::new("code").spawn().unwrap()` panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in [a comment](e7fda447e7/library/std/src/sys/windows/process.rs (L425)), but it makes sense to mention it at a more visible place.
I've added this clarification to the documentation, which should make it more accurate and helpful for Rust developers working on the Windows platform.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
In the current documentation, it's not specified that when creating
a Command, the .exe extension can be omitted for Windows executables.
However, for other types of executable files like .bat or .cmd,
the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()`
succeeds on my machine while `Command::new("code").spawn().unwrap()`
panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in a comment[1], but it
makes sense to mention it at more visible place.
I've added this clarification to the documentation, which should
make it more accurate and helpful for Rust developers
working on the Windows platform.
[1] e7fda447e7/library/std/src/sys/windows/process.rs (L425)
Like the other CStr and CString error types, make a re-export for
std::ffi::FromBytesUntilNulError.
This seems to have slipped through the cracks in the
cstr_from_bytes_until_nul implementation and core_c_str migration.
Tracking Issue: #95027
Adjustments for RustyHermit
The interface between `libstd` and the OS changed and some changes are not correctly merged for RustHermit. For instance, the crate `hermit_abi` isn't defined as public, although it provided the socket interface for the application.
In addition, the support of thread::available_parallelism is realized. It returns the number of available processors.
Add `Read`, `Write` and `Seek` impls for `Arc<File>` where appropriate
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
move pal cfgs in f32 and f64 to sys
I'd like to push forward on `sys` being a separate crate. To start with, most of these PAL exception cases are very simple little bits of code like this, so I thought I would try tidying them up.
Revert the lexing of `c"…"` string literals
Fixes \[after beta-backport\] #113235.
Further progress is tracked in #113333.
This PR *manually* reverts parts of #108801 (since a git-revert would've been too coarse-grained & messy)
and git-reverts #111647.
CC `@fee1-dead` (#108801) `@klensy` (#111647)
r? `@compiler-errors`
`@rustbot` label F-c_str_literals beta-nominated
`Path::with_extension` used to reallocate (and copy) paths twice per
call, now it does it once, by checking the size of the previous and new
extensions it's possible to call `PathBuf::with_capacity` and pass the
exact capacity it takes.
Also reduce the memory consumption of the path returned from
`Path::with_extension` by using exact capacity instead of using
amortized exponential growth.
Move windows-sys arm32 shim to c.rs
This moves the arm32 shim in to c.rs instead of appending to the generated file itself.
This makes it simpler to change these workarounds if/when needed. The downside is we need to exclude a couple of functions from being generated (see the comment). A metadata solution could help here but they'll be easy enough to add back if that happens.
Remove unnecessary `path` attribute
Follow up to #111401. I missed this at the time but it should now be totally unnecessary since the other include was removed.
r? `@workingjubilee`
Expose `compiler-builtins-weak-intrinsics` feature for `-Zbuild-std`
This was added in rust-lang/compiler-builtins#526 to force all compiler-builtins intrinsics to use weak linkage.
Implement `Sync` for `mpsc::Sender`
`mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in #93563. `mpsc::Sender` can now soundly implement `Sync`.
Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send + Clone` *sender*, not *receiver*.
It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP.
`@rustbot` label +T-libs-api -T-libs
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
Document memory orderings of `thread::{park, unpark}`
Document `thread::park/unpark` as having acquire/release synchronization. Without that guarantee, even the example in the documentation can deadlock:
```rust
let flag = Arc::new(AtomicBool::new(false));
let t2 = thread::spawn(move || {
while !flag.load(Ordering::Acquire) {
thread::park();
}
});
flag.store(true, Ordering::Release);
t2.thread().unpark();
// t1: flag.store(true)
// t1: thread.unpark()
// t2: flag.load() == false
// t2 now parks, is immediately unblocked but never
// acquires the flag, and thus spins forever
```
Multiple calls to `unpark` should also maintain a release sequence to make sure operations released by previous `unpark`s are not lost:
```rust
let a = Arc::new(AtomicBool::new(false));
let b = Arc::new(AtomicBool::new(false));
let t2 = thread::spawn(move || {
while !a.load(Ordering::Acquire) || !b.load(Ordering::Acquire) {
thread::park();
}
});
thread::spawn(move || {
a.store(true, Ordering::Release);
t2.thread().unpark();
});
b.store(true, Ordering::Release);
t2.thread().unpark();
// t1: a.store(true)
// t1: t2.unpark()
// t3: b.store(true)
// t3: t2.unpark()
// t2 now parks, is immediately unblocked but never
// acquires the store of `a`, only the store of `b` which
// was released by the most recent unpark, and thus spins forever
```
This is of course a contrived example, but is reasonable to rely upon in real code.
Note that all implementations of park/unpark already comply with the rules, it's just undocumented.
std: only depend on dlmalloc for wasm*-unknown
It was already filtered out for emscripten, but wasi doesn't need dlmalloc
either since it reuses `unix/alloc.rs`.
io: soften ‘at most one write attempt’ requirement in io::Write::write
At the moment, documentation of std::io::Write::write indicates that
call to it ‘represents at most one attempt to write to any wrapped
object’. It seems that such wording was put there to contrast it with
pre-1.0 interface which attempted to write all the data (it has since
been changed in [RFC 517]).
However, the requirement puts unnecessary constraints and may
complicate adaptors which perform non-trivial transformations on the
data. For example, they may maintain an internal buffer which needs
to be written out before the write method accepts more data. It might
be natural to code the method such that it flushes the buffer and then
grabs another chunk of user data. With the current wording in the
documentation, the adaptor would be forced to return Ok(0).
This commit softens the wording such that implementations can choose
code structure which makes most sense for their particular use case.
While at it, elaborate on the meaning of `Ok(0)` return pointing out
that the write_all methods interprets it as an error.
[RFC 517]: https://rust-lang.github.io/rfcs/0517-io-os-reform.html
fix: get the l4re target working again
This is based on work from https://github.com/rust-lang/rust/pull/103966, addressing the review comment by `@m-ou-se` at the time and "fixing" the (probably newly) missing read_buf.
Rollup of 6 pull requests
Successful merges:
- #112352 (Fix documentation build on FreeBSD)
- #112644 (Correct types in method descriptions of `NonZero*` types)
- #112683 (fix ICE on specific malformed asm clobber_abi)
- #112707 ([rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled)
- #112719 (Replace fvdl with ffx, allow test without install)
- #112728 (Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix documentation build on FreeBSD
After the socket ancillary data implementation was introduced, the documentation build was broken on FreeBSD hosts, add the same workaround as for the existing implementations.
Fixes the doc build after #91793
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
Fix building libstd documentation on FreeBSD.
It fixes the following error:
```
error[E0412]: cannot find type `sockcred2` in module `libc`
--> library/std/src/os/unix/net/ancillary.rs:211:29
|
211 | pub struct SocketCred(libc::sockcred2);
| ^^^^^^^^^ not found in `libc`
```
Implement `TryFrom<&OsStr>` for `&str`
Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing.
Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`.
As this is a trait implementation, it is insta-stable, if I'm not mistaken?
Either way this will need an FCP.
I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off.
`@rustbot` modify labels: +T-libs-api
API Change Proposal: rust-lang/rust#99031 (accepted)
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
It fixes the following error:
error[E0412]: cannot find type `sockcred2` in module `libc`
--> library/std/src/os/unix/net/ancillary.rs:211:29
|
211 | pub struct SocketCred(libc::sockcred2);
| ^^^^^^^^^ not found in `libc`
It might happen that a synthetic target name does not match one of the
hardcoded ones in std's build script, causing std to fail to build. This
commit changes the std build script avoid including the restricted-std
feature unconditionally when a synthetic target is being built.
Avoid unwind across `extern "C"` in `thread_local::fast_local`
This is a minimal fix for #112285, in case we want a simple patch that can be easily to backported if that's desirable.
*(Note: I have another broader cleanup which I've mostly omitted from here to avoid clutter, except for the `Cell` change, which isn't needed to fix UB, but simplifies safety comments).*
The only tier-1 target that this occurs on in a way that seems likely to cause problems in practice linux-gnu, although I believe some folks care about that platform somewhat 😉. I'm unsure how big of an issue this is. I've seen stuff like this behave quite badly, but there's a number of reasons to think this might actually be "fine in practice".
I've hedged my bets and assumed we'll backport this at least to beta but my feeling is that there's not enough evidence this is a problem worth backporting further than that.
### More details
This issue seems to have existed since `thread_local!`'s `const` init functionality was added. It occurs if you have a `const`-initialized thread local for a type that `needs_drop`, the drop panics, and you're on a target with support for static thread locals. In this case, we will end up defining an `extern "C"` function in the user crate rather than in libstd, and because the user crate will not have `#![feature(c_unwind)]` enabled, their panic will not be caught by an auto-inserted abort guard.
In practice, the actual situation where problems are likely[^ub] is somewhat narrower.
On most targets with static thread locals, we manage the TLS dtor list by hand (for reentrancy reasons among others). In these cases, while the users code may panic, we're calling it inside our own `extern "C"` (or `extern "system"`) function, which seems to (at least in practice) catch the panic and convert it to an abort.
However, on a few targets, most notably linux-gnu with recent glibc (but also fuchsia and redox), a tls dtor registration mechanism exists which we can actually use directly, [`__cxa_thread_atexit_impl`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/thread_local_dtor.rs#L26-L36).
This is the case that seems most likely to be a cause for concern, as now we're passing a function to the system library and panicking out of it in a case where there are may not be Rust frames above it on the call stack (since it's running thread shutdown), and even if there were, it may not be prepared to handle such unwinding. If that's the case, it'd be bad.
Is it? Dunno. The fact that it's a `__cxa_*` function makes me think they probably have considered that the callback could throw but I have no evidence here and it doesn't seem to be written down anywhere, so it's just a guess. (I would not be surprised if someone comes into this thread to tell me how definitely-bad-news it is).
That said, as I said, all this is actually UB! If this isn't a "technically UB but fine in practice", but all bets are off if this is the kind of thing we are telling LLVM about.
[^ub]: This is UB so take that with a grain of salt -- I'm absolutely making assumptions about how the UB will behave "in practice" here, which is almost certainly a mistake.
After the socket ancillary data implementation was introduced, the
build was broken on FreeBSD, add the same workaround as for the
existing implementations.
QNX Neutrino: exponential backoff when fork/spawn needs a retry
Fixes#108594: When retrying, sleep with an exponential duration. When sleep duration is lower than minimum possible sleeping time, yield instead (this will not be often due to the exponential increase of duration).
Minimum possible sleeping time is determined using `libc::clock_getres` but only when spawn/fork failed the first time in a request. This is cached using a LazyLock.
CC `@gh-tr`
r? `@workingjubilee`
`@rustbot` label +O-neutrino
use c literals in compiler and library
Use c literals #108801 in compiler and library
currently blocked on:
* <strike>rustfmt: don't know how to format c literals</strike> nope, nightly one works.
* <strike>bootstrap</strike>
r? `@ghost`
`@rustbot` blocked
