| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Move some std tests to integration tests
Unit tests directly inside of standard library crates require a very fragile way of building that is hard to reproduce outside of bootstrap.
Follow up to https://github.com/rust-lang/rust/pull/133859
|
|
OnceCell & OnceLock docs: Using (un)initialized consistently
Changed
* `set` / `initialize` / `full` to `initialized state`
* `uninitialize` / `empty` to `uninitialized state`
* `f` to `f()`
* Added explaination of `uninitialized state` & `initialized state`
[OnceCell Docs](https://doc.rust-lang.org/nightly/std/cell/struct.OnceCell.html)
[OnceLock Docs](https://doc.rust-lang.org/nightly/std/sync/struct.OnceLock.html)
Fixes #85716
``@rustbot`` label +A-docs
|
|
|
|
Stabilize `once_wait`
Closes: https://github.com/rust-lang/rust/issues/127527.
`@rustbot` label: +T-libs-api
r? libs-api
|
|
docs: Documented Send and Sync requirements for Mutex + MutexGuard
This an attempt to continue where #123225 left off.
I did some light clean up from the work done in that PR.
I also documented the `!Send` + `Sync` implementations for `MutexGuard` to the best of my knowledge.
Let me know if I got anything wrong :smile:
fixes #122856
cc: ``@IoaNNUwU``
r? ``@joboet``
|
|
|
|
|
|
|
|
This removes two minor OnceLock tests which test private methods. The
rest of the tests should be more than enough to catch mistakes in those
private methods. Also makes ReentrantLock::try_lock public. And finally
it makes the mpmc tests actually run.
|
|
|
|
Signed-off-by: crystalstall <crystalruby@qq.com>
|
|
|
|
This removes boilerplate around `Arc`s and makes the code more clear.
|
|
|
|
miri: disable test_downgrade_observe test on macOS
Due to https://github.com/rust-lang/rust/issues/121950, this test can fail on Miri. The test is also quite slow on Miri (taking more than 30s) due to the high iteration count (a total of 2000), so let's reduce that a little.
Fixes https://github.com/rust-lang/rust/issues/133421
|
|
|
|
std: allow after-main use of synchronization primitives
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.
|
|
|
|
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?~~
|
|
|
|
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
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.
|
|
|
|
|
|
lolbinarycat:library-fix-too_long_first_doc_paragraph, r=tgross35
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.
|
|
|
|
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
|
|
Signed-off-by: Xinye <xinye.tao@metabit-trading.com>
|
|
r=Mark-Simulacrum
Document `PartialEq` impl for `OnceLock`
Adds documentation to `std::sync::OnceLock`'s `PartialEq` implementation: specifies publicly that `OnceLock`s are compared based on their contents, and nothing else.
Created in response to, but not directly related to, https://github.com/rust-lang/rust/issues/131959.
## ne
This doesn't create and document `PartialEq::ne`. There's precedent for this in [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html#impl-PartialEq-for-RefCell%3CT%3E).
|
|
|
|
|
|
|
|
Add multi-producer, multi-consumer channel (mpmc)
Closes #125712
Tracking issue: #126840
r? m-ou-se
|
|
|
|
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
|
|
Disallow hidden references to mutable static
Closes #123060
Tracking:
- https://github.com/rust-lang/rust/issues/123758
|
|
Implement ACP 429: add `Lazy{Cell,Lock}::get[_mut]` and `force_mut`
Tracking issue for `lazy_get`: https://github.com/rust-lang/rust/issues/129333
|
|
|
|
|
|
In the implementation of `force_mut`, I chose performance over safety.
For `LazyLock` this isn't really a choice; the code has to be unsafe.
But for `LazyCell`, we can have a full-safe implementation, but it will
be a bit less performant, so I went with the unsafe approach.
|
|
The top-level docs for `LazyLock` included two lines of code, each
with an accompanying comment, that were identical and with nearly-
identical comments. This looks like an oversight from a past edit
which was perhaps trying to rewrite an existing example but ended
up duplicating rather than replacing, though I haven't gone back
through the Git history to check.
This commit removes what I personally think is the less-clear of
the two examples.
Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
|
|
|
|
The existing phrasing implies that a notification must be received for `wait_while` to return. The phrasing is changed to better reflect the behavior.
|
|
chore: remove repetitive words
|
|
Remove stray word in a comment
|
