| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Allow shared access to `Exclusive<T>` when `T: Sync`
Addresses libs-api request in https://github.com/rust-lang/rust/issues/98407#issuecomment-3299348713.
Adds the following trait impls to `Exclusive<T>`, all bounded on `T: Sync`:
- `AsRef<T>`
- `Clone`
- `Copy`
- `PartialEq`
- `StructuralPartialEq`
- `Eq`
- `Hash`
- `PartialOrd`
- `Ord`
- `Fn`
``@rustbot`` label T-libs-api
|
|
|
|
|
|
Constify conversion traits (part 1)
This is the first part of rust-lang/rust#144289 being split into smaller pieces. It adds/moves constness of several traits under the `const_convert` feature:
* `From`
* `Into`
* `TryFrom`
* `TryInto`
* `FromStr`
* `AsRef`
* `AsMut`
* `Borrow`
* `BorrowMut`
* `Deref`
* `DerefMut`
There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over `AsRef`:
* `ByteStr::new` (unstable under `bstr` feature)
* `OsStr::new`
* `Path::new`
Those which directly use `Into`:
* `Result::into_ok`
* `Result::into_err`
And those which use `Deref` and `DerefMut`:
* `Pin::as_ref`
* `Pin::as_mut`
* `Pin::as_deref_mut`
* `Option::as_deref`
* `Option::as_deref_mut`
* `Result::as_deref`
* `Result::as_deref_mut`
(note: the `Option` and `Result` methods were suggested by ``@npmccallum`` initially as rust-lang/rust#146101)
The parts which are missing from this PR are:
* Anything that involves heap-allocated types
* Making any method const than the ones listed above
* Anything that could rely on the above, *or* could rely on system-specific code for `OsStr` or `Path` (note: this mostly makes these methods useless since `str` doesn't implement `AsRef<OsStr>` yet, but it's better to track the method for now and add impls later, IMHO)
r? ``@tgross35`` (who mostly already reviewed this)
|
|
|
|
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
|
|
update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs
Since https://github.com/rust-lang/rust/pull/128778, it's allowed to perform atomic read and non-atomic read on the same atomic at the same time. Update the `Atomic*::from_ptr` and `Atomic*::as_ptr` documentation to remove expressions such as `not allowed to mix atomic and non-atomic accesses`.
see also [std::sync::atomic](https://doc.rust-lang.org/std/sync/atomic/index.html#memory-model-for-atomic-accesses)
|
|
|
|
|
|
|
|
- Rewords existing Considerations section on `fetch_update` and friends
to make clear that the limitations are inherent to an implementation based on any
CAS operation, rather than the weak version of `compare_exchange` in particular
- Add Considerations to `compare_exchange` and `compare_exchange_weak`
which details similar considerations and when they may be relevant.
|
|
Add new Tier-3 targets: `loongarch32-unknown-none*`
MCP: https://github.com/rust-lang/compiler-team/issues/865
NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
|
|
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
|
|
|
|
This updates some doctests that fail to run on wasm. We will soon be
supporting cross-compiled doctests, and the test-various job fails to
run these tests. These tests fail because wasm32-wasip1 does not support
threads.
|
|
|
|
|
|
in core/alloc/std only for now, and ignoring test files
Co-authored-by: Pavel Grigorenko <GrigorenkoPV@ya.ru>
|
|
|
|
Currently this cannot be inlined, which among other things means it
can't be used in `compiler-builtins` [1]. These are trivial functions
that should be inlineable, so add `#[inline]`.
[1]: https://github.com/rust-lang/compiler-builtins/pull/790#issuecomment-2744371738
|
|
Remove `#[cfg(not(test))]` gates in `core`
These gates are unnecessary now that unit tests for `core` are in a separate package, `coretests`, instead of in the same files as the source code. They previously prevented the two `core` versions from conflicting with each other.
|
|
Update documentation to consistently use 'm' in atomic synchronization example
Fixes #135801
|
|
atomic: clarify that failing conditional RMW operations are not 'writes'
Fixes https://github.com/rust-lang/rust/issues/136669
r? ``@Amanieu``
Cc ``@rust-lang/opsem`` ``@chorman0773`` ``@gnzlbg`` ``@briansmith``
|
|
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
|
|
These gates are unnecessary now that unit tests for `core` are in a
separate package, `coretests`, instead of in the same files as the
source code. They previously prevented the two `core` versions from
conflicting with each other.
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135869 (Make docs for AtomicUsize::from_mut platform-independent)
- #135892 (-Znext-solver: "normalize" signature before checking it mentions self in `deduce_closure_signature`)
- #136055 (Implement MIR const trait stability checks)
- #136066 (Pass spans to `perform_locally_in_new_solver`)
- #136071 ([Clippy] Add vec_reserve & vecdeque_reserve diagnostic items)
- #136124 (Arbitrary self types v2: explain test.)
- #136149 (Flip the `rustc-rayon`/`indexmap` dependency order)
- #136173 (Update comments and sort target_arch in c_char_definition)
- #136178 (Update username in build helper example)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Make docs for AtomicUsize::from_mut platform-independent
fixes #133342
|
|
Implement `AtomicT::update` & `AtomicT::try_update`
ACP accepted in https://github.com/rust-lang/libs-team/issues/490
``@rustbot`` label +T-libs-api
|
|
platform-independent
|
|
|
|
|
|
|
|
|
|
Stabilize `const_atomic_from_ptr`
The API is already stable since https://github.com/rust-lang/rust/pull/115719, but const stability was blocked on `const_mut_refs`. Since that was recently stabilized, const stabilize the following:
```rust
// core::atomic
impl AtomicBool { pub const unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a AtomicBool; }
impl<T> AtomicPtr<T> { pub const unsafe fn from_ptr<'a>(ptr: *mut *mut T) -> &'a AtomicPtr<T>; }
impl AtomicU8 { pub const unsafe fn from_ptr<'a>(ptr: *mut u8) -> &'a AtomicU8; }
impl AtomicU16 { pub const unsafe fn from_ptr<'a>(ptr: *mut u16) -> &'a AtomicU16; }
impl AtomicU32 { pub const unsafe fn from_ptr<'a>(ptr: *mut u32) -> &'a AtomicU32; }
impl AtomicU64 { pub const unsafe fn from_ptr<'a>(ptr: *mut u64) -> &'a AtomicU64; }
impl AtomicUsize { pub const unsafe fn from_ptr<'a>(ptr: *mut usize) -> &'a AtomicUsize; }
impl AtomicI8 { pub const unsafe fn from_ptr<'a>(ptr: *mut i8) -> &'a AtomicI8; }
impl AtomicI16 { pub const unsafe fn from_ptr<'a>(ptr: *mut i16) -> &'a AtomicI16; }
impl AtomicI32 { pub const unsafe fn from_ptr<'a>(ptr: *mut i32) -> &'a AtomicI32; }
impl AtomicI64 { pub const unsafe fn from_ptr<'a>(ptr: *mut i64) -> &'a AtomicI64; }
impl AtomicIsize { pub const unsafe fn from_ptr<'a>(ptr: *mut isize) -> &'a AtomicIsize; }
```
|
|
|
|
The API is already stable since [1], but const stability was blocked on
`const_mut_refs`. Since that was recently stabilized, const stabilize
the following:
// core::atomic
impl AtomicBool { pub const unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a AtomicBool; }
impl<T> AtomicPtr<T> { pub const unsafe fn from_ptr<'a>(ptr: *mut *mut T) -> &'a AtomicPtr<T>; }
impl AtomicU8 { pub const unsafe fn from_ptr<'a>(ptr: *mut u8) -> &'a AtomicU8; }
impl AtomicU16 { pub const unsafe fn from_ptr<'a>(ptr: *mut u16) -> &'a AtomicU16; }
impl AtomicU32 { pub const unsafe fn from_ptr<'a>(ptr: *mut u32) -> &'a AtomicU32; }
impl AtomicU64 { pub const unsafe fn from_ptr<'a>(ptr: *mut u64) -> &'a AtomicU64; }
impl AtomicUsize { pub const unsafe fn from_ptr<'a>(ptr: *mut usize) -> &'a AtomicUsize; }
impl AtomicI8 { pub const unsafe fn from_ptr<'a>(ptr: *mut i8) -> &'a AtomicI8; }
impl AtomicI16 { pub const unsafe fn from_ptr<'a>(ptr: *mut i16) -> &'a AtomicI16; }
impl AtomicI32 { pub const unsafe fn from_ptr<'a>(ptr: *mut i32) -> &'a AtomicI32; }
impl AtomicI64 { pub const unsafe fn from_ptr<'a>(ptr: *mut i64) -> &'a AtomicI64; }
impl AtomicIsize { pub const unsafe fn from_ptr<'a>(ptr: *mut isize) -> &'a AtomicIsize; }
Closes: <https://github.com/rust-lang/rust/issues/108652>
[1]: <https://github.com/rust-lang/rust/pull/115719>
|
|
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.
|
|
|
|
stabilize const_cell_into_inner
This const-stabilizes
- `UnsafeCell::into_inner`
- `Cell::into_inner`
- `RefCell::into_inner`
- `OnceCell::into_inner`
`@rust-lang/wg-const-eval` this uses `rustc_allow_const_fn_unstable(const_precise_live_drops)`, so we'd be comitting to always finding *some* way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller.
`@rust-lang/libs-api` this was FCP'd already [years ago](https://github.com/rust-lang/rust/issues/78729#issuecomment-811409860), except that `OnceCell::into_inner` was added to the same feature gate since then (Cc `@tgross35).` Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move `OnceCell` into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.
|
|
- UnsafeCell: mention the term "data race", and reference the data race definition
- atomic: failing RMWs are just reads, reorder and reword docs
|
|
|
