This is explicitly mentioned for std::fs::remove_file's documentation,
but not in the aforementioned function.
It is more likely for a slightly lazy programmer to believe that
removing a file would work and that they do not have to distinguish
between directories (with contents) and files themself, because of the
function's recursive nature and how it distinguishes between files and
directories when removing them.
Emscripten: link with -sWASM_BIGINT
When linking an executable without dynamic linking, this is a pure improvement. It significantly reduces code size and avoids a lot of buggy behaviors. It is supported in all browsers for many years and in all maintained versions of Node.
It does change the ABI, so people who are dynamically linking with a library or executable that uses the old ABI may need to turn it off. It can be disabled if needed by passing `-Clink-arg -sWASM_BIGINT=0` to `rustc`. But few people will want to turn it off.
Note this includes a libc bump to 0.2.162!
Mark `get_mut` and `set_position` in `std::io::Cursor` as const.
Relevant tracking issue: #130801
The methods `get_mut` and `set_position` can trivially be marked as const due to #57349 being stabilised.
Rollup of 4 pull requests
Successful merges:
- #131081 (Use `ConstArgKind::Path` for all single-segment paths, not just params under `min_generic_const_args`)
- #132577 (Report the `unexpected_cfgs` lint in external macros)
- #133023 (Merge `-Zhir-stats` into `-Zinput-stats`)
- #133200 (ignore an occasionally-failing test in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve `{BTreeMap,HashMap}::get_key_value` docs.
They are unusual methods. The docs don't really describe the cases when they might be useful (as opposed to just `get`), and the examples don't demonstrate the interesting cases at all.
This commit improves the docs and the examples.
When upgrading [Zed](https://github.com/zed-industries/zed/pull/19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82
Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773844
As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81;
the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously.
With 1.82 and 736f773844 it is no longer the case, thus we're seeing the hang.
This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer.
Previously we'd only terminate the loop if readdir returned 0.
By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.
This also fixes an inefficiency in the queue-based `RwLock`: if `thread::current` was not initialized yet, it will create a new handle on every parking attempt without initializing `thread::current`. The private `current_or_unnamed` function introduced here fixes this.
Rwlock downgrade
Tracking Issue: #128203
This PR adds a `downgrade` method for `RwLock` / `RwLockWriteGuard` on all currently supported platforms.
Outstanding questions:
- [x] ~~Does the `futex.rs` change affect performance at all? It doesn't seem like it will but we can't be certain until we bench it...~~
- [x] ~~Should the SOLID platform implementation [be ported over](https://github.com/rust-lang/rust/pull/128219#discussion_r1693470090) to the `queue.rs` implementation to allow it to support downgrades?~~
They are unusual methods. The docs don't really describe the cases when
they might be useful (as opposed to just `get`), and the examples don't
demonstrate the interesting cases at all.
This commit improves the docs and the examples.
This commit fixes a memory ordering bug in the futex implementation
(`Relaxed` -> `Release` on `downgrade`).
This commit also removes a badly written test that deadlocked and
replaces it with a more reasonable test based on an already-tested
`downgrade` test from the parking-lot crate.
This commit adds the `downgrade` method onto the inner `RwLock` queue
implementation.
There are also a few other style patches included in this commit.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
This commit only has documentation changes and a few things moved around
the file. The very few code changes are cosmetic: changes like turning a
`match` statement into an `if let` statement or reducing indentation for
long if statements.
This commit also adds several safety comments on top of `unsafe` blocks
that might not be immediately obvious to a first-time reader.
Code "changes" are in:
- `add_backlinks_and_find_tail`
- `lock_contended`
A majority of the changes are just expanding the comments from 80
columns to 100 columns.
[illumos] use pipe2 to create anonymous pipes
pipe2 allows the newly-created pipe to atomically be CLOEXEC.
pipe2 was added to illumos a long time ago:
5dbfd19ad5. I've verified that this change passes all of std's tests on illumos.
Fix compilation error on Solaris due to flock usage
PR 130999 added the file_lock feature, but libc does not define flock() for the Solaris platform leading to a compilation error.
Additionally, I went through all the Tier 2 platforms and read through their documentation to see whether flock was implemented. This turned up 5 more Unix platforms where flock is not supported, even though it may exist in the libc crate.
Fixes https://github.com/rust-lang/rust/issues/132921
Related to #130999
Fix a copy-paste issue in the NuttX raw type definition
This file is copied from the rtems as initial implementation, and forgot to change the OS name in the comment.
This file is copied from the rtems as initial implementation, and
forgot to change the OS name in the comment.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Make `CloneToUninit` dyn-compatible
Make `CloneToUninit` dyn-compatible, by making `clone_to_uninit`'s `dst` parameter `*mut u8` instead of `*mut Self`, so the method does not reference `Self` except in the `self` parameter and is thus dispatchable from a trait object.
This allows, among other things, adding `CloneToUninit` as a supertrait bound for `trait Foo` to allow cloning `dyn Foo` in some containers. Currently, this means that `Rc::make_mut` and `Arc::make_mut` can work with `dyn Foo` where `trait Foo: CloneToUninit`.
<details><summary>Example</summary>
```rs
#![feature(clone_to_uninit)]
use std::clone::CloneToUninit;
use std::rc::Rc;
use std::fmt::Debug;
use std::borrow::BorrowMut;
trait Foo: BorrowMut<u32> + CloneToUninit + Debug {}
impl<T: BorrowMut<u32> + CloneToUninit + Debug> Foo for T {}
fn main() {
let foo: Rc<dyn Foo> = Rc::new(42_u32);
let mut bar = foo.clone();
*Rc::make_mut(&mut bar).borrow_mut() = 37;
dbg!(foo, bar); // 42, 37
}
```
</details>
Eventually, `Box::<T>::clone` is planned to be converted to use `T::clone_to_uninit`, which when combined with this change, will allow cloning `Box<dyn Foo>` where `trait Foo: CloneToUninit` without any additional `unsafe` code for the author of `trait Foo`.[^1]
This PR should have no stable side-effects, as `CloneToUninit` is unstable so cannot be mentioned on stable, and `CloneToUninit` is not used as a supertrait anywhere in the stdlib.
This change removes some length checks that could only fail if library UB was already hit (e.g. calling `<[T]>::clone_to_uninit` with a too-small-length `dst` is library UB and was previously detected[^2]; since `dst` does not have a length anymore, this now cannot be detected[^3]).
r? libs-api
-----
I chose to make the parameter `*mut u8` instead of `*mut ()` because that might make it simpler to pass the result of `alloc` to `clone_to_uninit`, but `*mut ()` would also make sense, and any `*mut ConcreteType` would *work*. The original motivation for [using specifically `*mut ()`](https://github.com/rust-lang/rust/pull/116113#discussion_r1335303908) appears to be `std::ptr::from_raw_parts_mut`, but that now [takes `*mut impl Thin`](https://doc.rust-lang.org/nightly/std/ptr/fn.from_raw_parts.html) instead of `*mut ()`. I have another branch where the parameter is `*mut ()`, if that is preferred.
It *could* also take something like `&mut [MaybeUninit<u8>]` to be dyn-compatible but still allow size-checking and in some cases safe writing, but this is already an `unsafe` API where misuse is UB, so I'm not sure how many guardrails it's worth adding here, and `&mut [MaybeUninit<u8>]` might be overly cumbersome to construct for callers compared to `*mut u8`
[^1]: Note that `impl<T: CloneToUninit + ?Sized> Clone for Box` must be added before or at the same time as when `CloneToUninit` becomes stable, due to `Box` being `#[fundamental]`, as if there is any stable gap between the stabilization of `CloneToUninit` and `impl<T: CloneToUninit + ?Sized> Clone for Box`, then users could implement both `CloneToUninit for dyn LocalTrait` and separately `Clone for Box<dyn LocalTrait>` during that gap, and be broken by the introduction of `impl<T: CloneToUninit + ?Sized> Clone for Box`.
[^2]: Using a `debug_assert_eq` in [`core::clone::uninit::CopySpec::clone_slice`](https://doc.rust-lang.org/nightly/src/core/clone/uninit.rs.html#28).
[^3]: This PR just uses [the metadata (length) from `self`](e0c1c8bc50/library/core/src/clone.rs (L286)) to construct the `*mut [T]` to pass to `CopySpec::clone_slice` in `<[T]>::clone_to_uninit`.
float types: move copysign, abs, signum to libcore
These operations are explicitly specified to act "bitwise", i.e. they just act on the sign bit and do not even quiet signaling NaNs. We also list them as ["non-arithmetic operations"](https://doc.rust-lang.org/nightly/std/primitive.f32.html#nan-bit-patterns), and all the other non-arithmetic operations are in libcore. There's no reason to expect them to require any sort of runtime support, and from [these experiments](https://github.com/rust-lang/rust/issues/50145#issuecomment-997301250) it seems like LLVM indeed compiles them in a way that does not require any sort of runtime support.
Nominating for `@rust-lang/libs-api` since this change takes immediate effect on stable.
Part of https://github.com/rust-lang/rust/issues/50145.
PR 130999 added the file_lock feature, but libc does not define
flock() for the Solaris platform leading to a compilation error.
Additionally, I went through all the Tier 2 platforms and read through
their documentation to see whether flock was implemented. This turned up
5 more Unix platforms where flock is not supported, even though it may
exist in the libc crate.
pipe2 allows the newly-created pipe to atomically be CLOEXEC.
pipe2 was added to illumos a long time ago:
5dbfd19ad5.
I've verified that this change passes all tests.
split up the first paragraph of doc comments for better summaries
used `./x clippy -Aclippy::all '-Wclippy::too_long_first_doc_paragraph' library/core library/alloc` to find these issues.
When linking an executable without dynamic linking, this is a pure improvement.
It significantly reduces code size and avoids a lot of buggy behaviors. It is
supported in all browsers for many years and in all maintained versions of
Node.
It does change the ABI, so people who are dynamically linking with a library
or executable that uses the old ABI may need to turn it off. It can be disabled
if needed by passing `-Clink-arg -sWASM_BIGINT=0` to `rustc`. But few people
will want to turn it off.
Implement file_lock feature
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and unlock() to File gated behind the file_lock feature flag
This is the initial implementation of https://github.com/rust-lang/rust/issues/130994 for Unix and Windows platforms. I will follow it up with an implementation for WASI preview 2
Initialize channel `Block`s directly on the heap
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes#102246
try-job: test-various
Compile `test_num_f128` conditionally on `reliable_f128_math` config
With #132434 merged, our internal SGX CI started failing with:
```
05:27:34 = note: rust-lld: error: undefined symbol: fmodl
05:27:34 >>> referenced by arith.rs:617 (core/src/ops/arith.rs:617)
05:27:34 >>> /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/std-5d5f11eb008c9091.std.d8141acc61ab7ac8-cgu.10.rcgu.o:(std::num::test_num::h7dd9449f6c01fde8)
05:27:34 >>> did you mean: fmodf
05:27:34 >>> defined in: /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/libcompiler_builtins-0376f439a2ebf305.rlib(compiler_builtins-0376f439a2ebf305.compiler_builtins.c22db39d25d6f802-cgu.148.rcgu.o)
```
This originated from the `test_num_f128` test not having the required conditional compilation. This PR fixes that issue.
cc: ````@jethrogb,```` ````@workingjubilee````
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes#102246
unpin and update memchr
I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by https://github.com/rust-lang/rust/pull/129079Fixes#127890
Revert using `HEAP` static in Windows alloc
Fixes#131468
This does the minimum to remove the `HEAP` static that was causing chromium issues. It would be worth having a more substantial look at this module but for now I think this addresses the immediate issue.
cc `@danakj`
Fix an extra newline in rendered std doc
Fixes#132564
(taken from the issue above)
The problem with the formatting is due to that newline between `<code>` and `<svg>`. Any newlines outside of the code (i.e., within elements inside of it) are fine.
Update `compiler-builtins` and enable f128 tests on all non-buggy platforms
Update compiler_builtins to 0.1.138 and pin it. This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms.
With that, we now provide symbols necessary to work with `f128` everywhere. This means that we are no longer restricted to systems that provide `f128` symbols themselves, and can enable tests by default.
There are still a handful of platforms that need to remain disabled because of bugs and some that had to get updated.
Math support is still off by default since those symbols are not yet available.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
try-job: test-various
try-job: i686-gnu-nopt
With the `compiler-builtins` update to 0.1.137 [1], we now provide
symbols necessary to work with `f128` everywhere. This means that we are
no longer restricted to 64-bit linux, and can enable tests by default.
There are still a handful of platforms that need to remain disabled
because of bugs. This patch additionally disables the following:
1. MIPS [2]
2. 32-bit x86 [3]
Math support is still off by default since those symbols are not yet
available.
[1]: https://github.com/rust-lang/rust/pull/132433
[2]: https://github.com/llvm/llvm-project/issues/96432
[3]: https://github.com/llvm/llvm-project/issues/77401
This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms 🎉.
With this update, also change to pinning the version with `=` rather
than using the default carat versioning. This is meant to ensure that
`compiler-builtins` does not get updated as part of the weekly
`Cargo.lock` update, since updates to this crate need to be intentional:
changes to rust-lang/rust and rust-lang/compiler-builtins sometimes need
to be kept in lockstep, unlike most dependencies, and sometimes these
updates can be problematic.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
Make `std::os::darwin` public
I'm not sure of the reasoning behind them not being public before, but I think they should be, just like `std::os::ios` and `std::os::macos` are public.
Additionally, I've merged their source code, as it was otherwise just a bunch of unnecessary duplication.
Ultimately, I've done this PR to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Since you reviewed https://github.com/rust-lang/rust/pull/121419
r? davidtwco
Fixes https://github.com/rust-lang/rust/issues/121640.
`@rustbot` label O-tvos O-watchos O-visionos
better test for const HashMap; remove const_hash leftovers
The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.
The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.
Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes#104061
Related to https://github.com/rust-lang/rust/issues/102575
Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`
ACP: https://github.com/rust-lang/libs-team/issues/424
New API:
```rust
impl<T: Clone> From<&mut [T]> for Box<[T]>
impl From<&mut str> for Box<str>
impl From<&mut CStr> for Box<CStr>
impl From<&mut OsStr> for Box<OsStr>
impl From<&mut Path> for Box<Path>
impl<T: Clone> From<&mut [T]> for Rc<[T]>
impl From<&mut str> for Rc<str>
impl From<&mut CStr> for Rc<CStr>
impl From<&mut OsStr> for Rc<OsStr>
impl From<&mut Path> for Rc<Path>
impl<T: Clone> From<&mut [T]> for Arc<[T]>
impl From<&mut str> for Arc<str>
impl From<&mut CStr> for Arc<CStr>
impl From<&mut OsStr> for Arc<OsStr>
impl From<&mut Path> for Arc<Path>
```
Since they are trait implementations, I think these are insta-stable.
As mentioned in https://github.com/rust-lang/libs-team/issues/424#issuecomment-2299415749, a crater run might be needed.
Remove unintended link
Since `#[link_section]` is enclosed in braces, it was being confused with a link during docs compilation.
This caused compilation to fail when running `x dist` since it emitted a warning regarding broken links.
Fix type reference in documents which was being confused with html tags.
Running `x dist` was failing due to it invoking commands with `-D warnings`, which emitted a warning about unclosed html tags.
xous: sync: remove `rustc_const_stable` attribute on Condvar and Mutex new()
These functions had `#[rustc_const_stable(feature = "const_locks", since = "1.63.0")]` on them because they were originally taken from `no_threads`. with d066dfd these no longer compile. Since other platforms do not have this attribute, remove it. This fixes the build for Xous.
These functions had `#[rustc_const_stable(feature = "const_locks", since
= "1.63.0")]` on them because they were originally taken from
`no_threads`. with d066dfd these no longer compile. Since other
platforms do not have this attribute, remove it. This fixes the build
for Xous.
Signed-off-by: Sean Cross <sean@xobs.io>
The non-trivial code for `pthread_condvar` is duplicated across the thread parking and the `Mutex`/`Condvar` implementations. This PR moves that code into `sys::pal`, which now exposes a non-movable wrapper type for `pthread_mutex_t` and `pthread_condvar_t`.
Const stability checks v2
The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage:
- It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention.
- The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check.
Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories.
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required.
Also see the updated dev-guide at https://github.com/rust-lang/rustc-dev-guide/pull/2098.
I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`.
### Open question
There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics.
I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics.
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Part of https://github.com/rust-lang/rust/issues/129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown)
Fixes https://github.com/rust-lang/rust/issues/131073 by making it so that const-stable functions are always stable
try-job: test-various
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
Avoid using imports in thread_local_inner! in static
Fixes#131863 for wasm targets
All other macros were done in #131866, but this sub module is missed.
r? `@jieyouxu`
AIX: use /dev/urandom for random implementation
On AIX, we can poll `/dev/urandom` for cryptographically secure random output to implement `fill_bytes` because we don't have equivalent syscalls like other platforms. https://www.ibm.com/docs/en/aix/7.3?topic=files-random-urandom-devices
[musl] use posix_spawn if a directory change was requested
Currently, not all libcs have the `posix_spawn_file_actions_addchdir_np` symbol available to them. So we attempt to do a weak symbol lookup for that function. But that only works if libc is a dynamic library -- with statically linked musl binaries the symbol lookup would never work, so we would never be able to use it even if the musl in use supported the symbol.
Now that Rust has a minimum musl version of 1.2.3, all supported musl versions now include this symbol, so we can unconditionally expect it to be there. This symbol was added to libc in https://github.com/rust-lang/libc/pull/3949 -- use it here.
I couldn't find any tests for whether the posix_spawn path is used, but I've verified with cargo-nextest that this change works. This is a substantial improvement to nextest's performance with musl. On my workstation with a Ryzen 7950x, against https://github.com/clap-rs/clap at
61f5ee514f8f60ed8f04c6494bdf36c19e7a8126:
Before:
```
Summary [ 1.071s] 879 tests run: 879 passed, 0 skipped
```
After:
```
Summary [ 0.392s] 879 tests run: 879 passed, 0 skipped
```
Fixes#99740.
try-job: dist-various-1
try-job: dist-various-2
Remove the `Arc` rt::init allocation for thread info
Removes an allocation pre-main by just not storing anything in std:🧵:Thread for the main thread.
- The thread name can just be a hard coded literal, as was done in #123433.
- Storing ThreadId and Parker in a static that is initialized once at startup. This uses SyncUnsafeCell and MaybeUninit as this is quite performance critical and we don't need synchronization or to store a tag value and possibly leave in a panic.
Currently, not all libcs have the `posix_spawn_file_actions_addchdir_np` symbol
available to them. So we attempt to do a weak symbol lookup for that function.
But that only works if libc is a dynamic library -- with statically linked musl
binaries the symbol lookup would never work, so we would never be able to use it
even if the musl in use supported the symbol.
Now that Rust has a minimum musl version of 1.2.3, all supported musl versions
now include this symbol, so we can unconditionally expect it to be there. This
symbol was added to libc in https://github.com/rust-lang/libc/pull/3949 -- use
it here.
I couldn't find any tests for whether the posix_spawn path is used, but I've
verified with cargo-nextest that this change works. This is a substantial
improvement to nextest's performance with musl. On my workstation with a Ryzen
7950x, against https://github.com/clap-rs/clap at
61f5ee514f8f60ed8f04c6494bdf36c19e7a8126:
Before:
```
Summary [ 1.071s] 879 tests run: 879 passed, 0 skipped
```
After:
```
Summary [ 0.392s] 879 tests run: 879 passed, 0 skipped
```
Fixes#99740.
stabilize Strict Provenance and Exposed Provenance APIs
Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;
impl<T: ?Sized> *const T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> *mut T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn addr(self) -> NonZero<usize>;
pub fn with_addr(self, addr: NonZero<usize>) -> Self;
pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```
I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.
There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)
`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`
Part of https://github.com/rust-lang/rust/issues/95228.
[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
replace STATX_ALL with (STATX_BASIC_STATS | STATX_BTIME) as former is deprecated
STATX_ALL was deprecated in 581701b7ef and suggested to use equivalent (STATX_BASIC_STATS | STATX_BTIME) combination, to prevent future surprises.
Update `use` keyword docs to describe precise capturing
I noticed that the standard library keyword docs for the `use` keyword haven't been updated yet to describe the new precise capturing syntax.
Make `profiler_builtins` an optional dependency of sysroot, not std
This avoids unnecessary rebuilds of std (and the compiler) when `build.profiler` is toggled off or on.
Fixes#131812.
---
Background: The `profiler_builtins` crate has been an optional dependency of std (behind a cargo feature) ever since it was added back in #42433. But as far as I can tell that has only ever been a convenient way to force the crate to be built, not a genuine dependency.
The side-effect of this false dependency is that toggling `build.profiler` causes a rebuild of std and the compiler, which shouldn't be necessary. This PR therefore makes `profiler_builtins` an optional dependency of the dummy sysroot crate (#108865), rather than a dependency of std.
What makes this change so small is that all of the necessary infrastructure already exists. Previously, bootstrap would enable the `profiler` feature on the sysroot crate, which would forward that feature to std. Now, enabling that feature directly enables sysroot's `profiler_builtins` dependency instead.
---
I believe this is more of a bootstrap change than a libs change, so tentatively:
r? bootstrap
- Since in almost all cases, there will only be 1 UEFI shell, share the
shell handle between all functions that require it.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rollup of 3 pull requests
Successful merges:
- #126207 (std::unix::stack_overflow::drop_handler addressing todo through libc …)
- #131864 (Never emit `vptr` for empty/auto traits)
- #131870 (compiletest: Store test collection context/state in two structs)
r? `@ghost`
`@rustbot` modify labels: rollup
Abstract the state type for futexes
In the same way that we expose `SmallAtomic` and `SmallPrimitive` to allow Windows to use a value other than an `AtomicU32` for its futex state, switch the primary futex state type from `AtomicU32` to `futex::Futex`. The `futex::Futex` type should be usable as an atomic value with underlying primitive type equal to `futex::Primitive`. (`SmallAtomic` is also renamed to `SmallFutex`).
This allows supporting the futex API on systems where the underlying kernel futex implementation requires more user state than simply an `AtomicU32`.
All in-tree futex implementations simply define {`Futex`,`Primitive`} directly as {`AtomicU32`,`u32`}.
Avoid use imports in `thread_local_inner!`
Previously, the use imports in `thread_local_inner!` can shadow user-provided types or type aliases of the names `Storage`, `EagerStorage`, `LocalStorage` and `LocalKey`. This PR fixes that by dropping the use imports and instead refer to the std-internal types via fully qualified paths. A basic test is added to ensure `thread_local!`s with static decls with type names that match the aforementioned std-internal type names can successfully compile.
Fixes#131863.
Bump libc to 0.2.161
Bumps libc to the latest release version 0.2.161 which
- includes libc support for the tier 3 RTEMS target
- fixes segfaults on 32-bit FreeBSD targets
- gets musl's `posix_spawn_file_actions_addchdir_np` for some spawn opts
Various fixes for Xous
This patchset includes several fixes for Xous that have crept in over the last few months:
* The `adjust_process()` syscall was incorrect
* Warnings have started appearing in `alloc` -- adopt the same approach as wasm, until wasm figures out a workaround
* Dead code warnings have appeared in the networking code. Add `allow(dead_code)` as these structs are used as IPC values
* Add support for `args` and `env`, which have been useful for running tests
* Update `unwinding` to `0.2.3` which fixes the recent regression due to changes in `asm!()` code
In the same way that we expose SmallAtomic and SmallPrimitive to allow
Windows to use a value other than an AtomicU32 for its futex state, this
patch switches the primary futex state type from AtomicU32 to
futex::Atomic. The futex::Atomic type should be usable as an atomic
value with underlying primitive type equal to futex::Primitive.
This allows supporting the futex API on systems where the underlying
kernel futex implementation requires more state than simply an
AtomicU32.
All in-tree futex implementations simply define {Atomic,Primitive}
directly as {AtomicU32,u32}.
uefi: Implement getcwd and chdir
- Using EFI Shell Protocol. These functions do not make much sense unless a shell is present.
- Return the exe dir in case shell protocol is missing.
r? `@joboet`
Some float methods are now `const fn` under the `const_float_methods` feature gate.
In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval.
Autodiff Upstreaming - enzyme frontend
This is an upstream PR for the `autodiff` rustc_builtin_macro that is part of the autodiff feature.
For the full implementation, see: https://github.com/rust-lang/rust/pull/129175
**Content:**
It contains a new `#[autodiff(<args>)]` rustc_builtin_macro, as well as a `#[rustc_autodiff]` builtin attribute.
The autodiff macro is applied on function `f` and will expand to a second function `df` (name given by user).
It will add a dummy body to `df` to make sure it type-checks. The body will later be replaced by enzyme on llvm-ir level,
we therefore don't really care about the content. Most of the changes (700 from 1.2k) are in `compiler/rustc_builtin_macros/src/autodiff.rs`, which expand the macro. Nothing except expansion is implemented for now.
I have a fallback implementation for relevant functions in case that rustc should be build without autodiff support. The default for now will be off, although we want to flip it later (once everything landed) to on for nightly. For the sake of CI, I have flipped the defaults, I'll revert this before merging.
**Dummy function Body:**
The first line is an `inline_asm` nop to make inlining less likely (I have additional checks to prevent this in the middle end of rustc. If `f` gets inlined too early, we can't pass it to enzyme and thus can't differentiate it.
If `df` gets inlined too early, the call site will just compute this dummy code instead of the derivatives, a correctness issue. The following black_box lines make sure that none of the input arguments is getting optimized away before we replace the body.
**Motivation:**
The user facing autodiff macro can verify the user input. Then I write it as args to the rustc_attribute, so from here on I can know that these values should be sensible. A rustc_attribute also turned out to be quite nice to attach this information to the corresponding function and carry it till the backend.
This is also just an experiment, I expect to adjust the user facing autodiff macro based on user feedback, to improve usability.
As a simple example of what this will do, we can see this expansion:
From:
```
#[autodiff(df, Reverse, Duplicated, Const, Active)]
pub fn f1(x: &[f64], y: f64) -> f64 {
unimplemented!()
}
```
to
```
#[rustc_autodiff]
#[inline(never)]
pub fn f1(x: &[f64], y: f64) -> f64 {
::core::panicking::panic("not implemented")
}
#[rustc_autodiff(Reverse, Duplicated, Const, Active,)]
#[inline(never)]
pub fn df(x: &[f64], dx: &mut [f64], y: f64, dret: f64) -> f64 {
unsafe { asm!("NOP"); };
::core::hint::black_box(f1(x, y));
::core::hint::black_box((dx, dret));
::core::hint::black_box(f1(x, y))
}
```
I will add a few more tests once I figured out why rustc rebuilds every time I touch a test.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
try-job: dist-x86_64-msvc
- Using EFI Shell Protocol. These functions do not make much sense
unless a shell is present.
- Return the exe dir in case shell protocol is missing.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate
https://github.com/rust-lang/rust/issues/76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to https://github.com/rust-lang/rust/issues/76205.
std::fs::get_path freebsd update.
what matters is we re doing the right things as doing sizeof, rather than passing KINFO_FILE_SIZE (only defined on intel architectures), the kernel
making sure it matches the expectation in its side.
The allocator on Xous is now throwing warnings because the allocator
needs to be mutable, and allocators hand out mutable pointers, which
the `static_mut_refs` lint now catches.
Give the same treatment to Xous as wasm, at least until a solution is
devised for fixing the warning on wasm.
Signed-off-by: Sean Cross <sean@xobs.io>
Process arguments and environment variables are both passed by way of
Application Parameters. These are a TLV format that gets passed in as
the second process argument.
This patch combines both as they are very similar in their decode.
Signed-off-by: Sean Cross <sean@osdyne.com>
std: fix stdout-before-main
Fixes#130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
Fixes#130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
Migrate lib's `&Option<T>` into `Option<&T>`
Trying out my new lint https://github.com/rust-lang/rust-clippy/pull/13336 - according to the [video](https://www.youtube.com/watch?v=6c7pZYP_iIE), this could lead to some performance and memory optimizations.
Basic thoughts expressed in the video that seem to make sense:
* `&Option<T>` in an API breaks encapsulation:
* caller must own T and move it into an Option to call with it
* if returned, the owner must store it as Option<T> internally in order to return it
* Performance is subject to compiler optimization, but at the basics, `&Option<T>` points to memory that has `presence` flag + value, whereas `Option<&T>` by specification is always optimized to a single pointer.
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Decouple WASIp2 sockets from WasiFd
This is a follow up to #129638, decoupling WASIp2's socket implementation from WASIp1's `WasiFd` as discussed with `@alexcrichton.`
Quite a few trait implementations in `std::os::fd` rely on the fact that there is an additional layer of abstraction between `Socket` and `OwnedFd`. I thus had to add a thin `WasiSocket` wrapper struct that just "forwards" to `OwnedFd`. Alternatively, I could have added a lot of conditional compilation to `std::os::fd`, which feels even worse.
Since `WasiFd::sock_accept` is no longer accessible from `TcpListener` and since WASIp2 has proper support for accepting sockets through `Socket::accept`, the `std::os::wasi::net` module has been removed from WASIp2, which only contains a single `TcpListenerExt` trait with a `sock_accept` method as well as an implementation for `TcpListener`. Let me know if this is an acceptable solution.
Android: Debug assertion after setting thread name
While `prctl` cannot fail if it points to a valid buffer, it's still better to assert the result as it's done for other places.
