| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
generic function, and wrap it in `catch_unwind`
|
|
|
|
|
|
|
|
Stabilize `hint::assert_unchecked`
Make the following API stable, including const:
```rust
// core::hint, std::hint
pub const unsafe fn assert_unchecked(p: bool);
```
This PR also reworks some of the documentation and adds an example.
Tracking issue: https://github.com/rust-lang/rust/issues/119131
FCP: https://github.com/rust-lang/rust/issues/119131#issuecomment-1906394087. The docs update should resolve the remaining concern.
|
|
|
|
chore: remove duplicate words
remove duplicate words in comments to improve readability.
|
|
|
|
Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves #66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
|
|
qualified in process_vxworks.rs
|
|
std: separate TLS key creation from TLS access
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
Related to #110897.
|
|
|
|
set self.is_known_utf8 to false in extend_from_slice
try-job: x86_64-msvc
closes #126977
Related to #126885, #126333, and [this conversation](<https://github.com/rust-lang/rust/commit/aa46a3368eb017eba41bfab956c7787d46c09935#r143539097>)
|
|
Add more constants, functions, and tests for `f16` and `f128`
This adds everything that was in some way blocked on const eval, since https://github.com/rust-lang/rust/pull/126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change.
`f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64.
Tracking issue: https://github.com/rust-lang/rust/issues/116909
|
|
|
|
|
|
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
|
|
#126333
|
|
|
|
|
|
|
|
This suite tests all library functions that are now available for the
types. Tests are only run on certain platforms where `f16` and `f128`
are known to work (have symbols available and don't crash LLVM).
|
|
This adds everything that was directly or transitively blocked on const
arithmetic for these types, which was recently merged.
Since const arithmetic is recent, most of these need to be gated by
`bootstrap`.
Anything that relies on intrinsics that are still missing is excluded.
|
|
|
|
we now distinguish between pidfd_spawn support, pidfd-via-fork/exec and not-supported
|
|
|
|
|
|
|
|
Remove `MaybeUninit::uninit_array()` and replace it with inline const blocks.
\[This PR originally contained the changes in #125995 too. See edit history for the original PR description.]
The documentation of `MaybeUninit::uninit_array()` says:
> Note: in a future Rust version this method may become unnecessary when Rust allows [inline const expressions](https://github.com/rust-lang/rust/issues/76001). The example below could then use `let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];`.
The PR adding it also said: <https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a standard library method that will be replaceable with `let buffer = [MaybeUninit::<T>::uninit(); $N];`
That time has come to pass — inline const expressions are stable — so `MaybeUninit::uninit_array()` is now unnecessary. The only remaining question is whether it is an important enough *convenience* to keep it around.
I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (`MaybeUninit` and array construction) than to have a specific function for the specific combination, now that that is possible.
|
|
This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<https://github.com/rust-lang/rust/pull/65580#issuecomment-544200681>
> if it’s stabilized soon enough maybe it’s not worth having a
> standard library method that will be replaceable with
> `let buffer = [MaybeUninit::<T>::uninit(); $N];`
Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` other than convenience. Therefore,
let’s evaluate the inconvenience by not using `uninit_array()` in
the standard library, before potentially deleting it entirely.
|
|
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
|
|
|
|
|
|
This will make it easier to keep `f16` and `f128` consistent as their
implementations get added.
|
|
std::unix::os::home_dir: fallback's optimisation.
we're using a guaranteed initialised field on success.
|
|
std::unix::fs: copy simplification for apple.
since we do support from macOs Sierra, we avoid the little runtime overhead with the fclonefileat symbol check.
|
|
|
|
tguichaoua:fix_tcplistener_into_incoming_issue_number, r=workingjubilee
Fix issue number for the `tcplistener_into_incoming` feature
As per [this comment](https://github.com/rust-lang/rust/pull/88339#discussion_r922899044), the issue number for the `tcplistener_into_incoming` feature is the one of the PR that implements it instead of the tracking issue.
- https://github.com/rust-lang/rust/pull/88339
- https://github.com/rust-lang/rust/issues/88373
|
|
we're using a guaranteed initialised field on success.
|
|
Remove use of const traits (and `feature(effects)`) from stdlib
The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.
Also, make `effects` an incomplete feature.
cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
|
|
Rename `std::fs::try_exists` to `std::fs::exists` and stabilize fs_try_exists
FCP completed in tracking issue.
Tracking issue: https://github.com/rust-lang/rust/issues/83186
Closes https://github.com/rust-lang/rust/issues/83186
Stabilized API:
```rust
mod fs {
pub fn exists<P: AsRef<Path>>(path: P) -> io::Result<bool>;
}
```
|
|
Add PidFd::{kill, wait, try_wait}
#117957 changed `Child` kill/wait/try_wait to use its pidfd instead of the pid, when one is available.
This PR extracts those implementations and makes them available on `PidFd` directly.
The `PidFd` implementations differ significantly from the corresponding `Child` methods:
* the methods can be called after the child has been reaped, which will result in an error but will be safe. This state is not observable in `Child` unless something stole the zombie child
* the `ExitStatus` is not kept, meaning that only the first time a wait succeeds it will be returned
* `wait` does not close stdin
* `wait` only requires `&self` instead of `&mut self` since there is no state to maintain and subsequent calls are safe
Tracking issue: #82971
|
|
As long as a pidfd is on a child it can be safely reaped. Taking it
would mean the child would now have to be awaited through its pid, but could also
be awaited through the pidfd. This could then suffer from a recycling race.
|
|
|
|
since we do support from macOs Sierra, we avoid the little runtime overhead
with the fclonefileat symbol check.
|
|
|
|
|
|
1. Miri's exit is thread-safe
2. Miri doesn't (yet) support `libc::gettid`, used in the implementation of the mitigation on Linux.
|
|
|
