| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #127474 (doc: Make block of inline Deref methods foldable)
- #129678 (Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver)
- #129738 (`rustc_mir_transform` cleanups)
- #129793 (add extra linebreaks so rustdoc can identify the first sentence)
- #129804 (Fixed some typos in the standard library documentation/comments)
- #129837 (Actually parse stdout json, instead of using hacky contains logic.)
- #129842 (Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf)
- #129843 (Mark myself as on vacation for triagebot)
- #129858 (Replace walk with visit so we dont skip outermost expr kind in def collector)
Failed merges:
- #129777 (Add `unreachable_pub`, round 4)
- #129868 (Remove kobzol vacation status)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: cuishuang <imcusg@gmail.com>
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection)
- #126697 ([RFC] mbe: consider the `_` in 2024 an expression)
- #127159 (match lowering: Hide `Candidate` from outside the lowering algorithm)
- #128244 (Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks)
- #128431 (Add myself as VxWorks target maintainer for reference)
- #128438 (Add special-case for [T, 0] in dropck_outlives)
- #128457 (Fix docs for OnceLock::get_mut_or_init)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
std: implement the `once_wait` feature
Tracking issue: #127527
This additionally adds a `wait_force` method to `Once` that doesn't panic on poison.
I also took the opportunity and cleaned up up the code of the queue-based implementation a bit.
|
|
|
|
|
|
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
Use ThreadId instead of TLS-address in `ReentrantLock`
Fixes #123458
`ReentrantLock` currently uses the address of a thread local variable as an ID that's unique across all currently running threads. This can lead to uninituitive behavior as in #123458 if TLS blocks get reused. This PR changes `ReentrantLock` to instead use the `ThreadId` provided by `std` as the unique ID. `ThreadId` guarantees uniqueness across the lifetime of the whole process, so we don't need to worry about reusing IDs of terminated threads. The main appeal of this PR is thus the possibility of changing the `ReentrantLock` API to guarantee that if a thread leaks a lock guard, no other thread may ever acquire that lock again.
This does entail some complications:
- previously, the only way to retrieve the current thread ID would've been using `thread::current().id()` which creates a temporary `Arc` and which isn't available in TLS destructors. As part of this PR, the thread ID instead gets cached in its own thread local, as suggested [here](https://github.com/rust-lang/rust/issues/123458#issuecomment-2038207704).
- `ThreadId` is always 64-bit whereas the current implementation uses a usize-sized ID. Since this ID needs to be updated atomically, we can't simply use a single atomic variable on 32 bit platforms. Instead, we fall back to using a (sound) seqlock on 32-bit platforms, which works because only one thread at a time can write to the ID. This seqlock is technically susceptible to the ABA problem, but the attack vector to create actual unsoundness has to be very specific:
- You would need to be able to lock+unlock the lock exactly 2^31 times (or a multiple thereof) while a thread trying to lock it sleeps
- The sleeping thread would have to suspend after reading one half of the thread id but before reading the other half
- The teared result from combining the halves of the thread ID would have to exactly line up with the sleeping thread's ID
The risk of this occurring seems slim enough to be acceptable to me, but correct me if I'm wrong. This also means that the size of the lock increases by 8 bytes on 32-bit platforms, but this also shouldn't be an issue.
Performance wise, I did some crude testing of the only case where this could lead to real slowdowns, which is the case of locking a `ReentrantLock` that's already locked by the current thread. On both aarch64 and x86-64, there is (expectedly) pretty much no performance hit. I didn't have any 32-bit platforms to test the seqlock performance on, so I did the next best thing and just forced the 64-bit platforms to use the seqlock implementation. There, the performance degraded by ~1-2ns/(lock+unlock) on x86-64 and ~6-8ns/(lock+unlock) on aarch64, which is measurable but seems acceptable to me seeing as 32-bit platforms should be a small minority anyways.
cc `@joboet` `@RalfJung` `@CAD97`
|
|
This changes `ReentrantLock` to use `ThreadId` for the thread ownership check instead of the address of a thread local. Unlike TLS blocks, `ThreadId` is guaranteed to be unique across the lifetime of the process, so if any thread ever terminates while holding a `ReentrantLockGuard`, no other thread may ever acquire that lock again.
On platforms with 64-bit atomics, this is a very simple change. On other platforms, the approach used is slightly more involved, as explained in the module comment.
This also adds a `CURRENT_ID` thread local in addition to the already existing `CURRENT`. This allows us to access the current `ThreadId` without the relatively heavy machinery used by `thread::current().id()`.
|
|
|
|
This provides a list of locations to hunt down issues in.
|
|
r=Mark-Simulacrum
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067 https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
|
|
Name this something that is less confusable with an atomic consume API for
`{Lazy,Once}Lock`.
|
