Do not move thread-locals before dropping
Fixesrust-lang/rust#140816. I also (potentially) improved the speed of `get_or_init` a bit by having an explicit hot/cold path.
We still move the value before dropping in the event of a recursive initialization (leading to double-initialization with one value being silently dropped). This is the old behavior, but changing this to panic instead would involve changing tests and also the other OS-specific `thread_local/os.rs` implementation, which is more than I'd like in this PR.
gold has been deprecated recently and is known to behave incorrectly
around Rust programs, including miscompiling `#[used(linker)]`.
Tell people to switch to a different linker instead.
Co-Authored-By: bjorn3 <17426603+bjorn3@users.noreply.github.com>
Add fast path for maybe-initializedness in liveness
r? `@matthewjasper`
Correct me if I'm wrong Matthew, but my understanding is that
1. `MaybeInitializedPlaces` is currently eagerly computed, in `do_mir_borrowck`
2. but this data is only used in liveness
3. and `liveness::trace` actually only uses it for drop-liveness
This PR moves the computation to `liveness::trace` which looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness.
This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps.
It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon.
(I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)
This commit improves the Clone trait documentation to address confusion
around what "duplication" means for different types, especially for smart
pointers like Arc<Mutex<T>>.
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140825 (Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`)
- rust-lang/rust#141077 (Fix the issue of typo of comma in arm parsing)
- rust-lang/rust#141237 (Implement ((un)checked_)exact_div methods for integers)
- rust-lang/rust#141494 (mir-opt: Do not transform non-int type in match_branches)
- rust-lang/rust#141609 (core: begin deduplicating pointer docs)
- rust-lang/rust#141768 (ci: use arm to calculate job matrix)
- rust-lang/rust#141771 (Increase timeout for new bors try builds)
- rust-lang/rust#141781 (Fix spans for unsafe binders)
r? `@ghost`
`@rustbot` modify labels: rollup
core: begin deduplicating pointer docs
this also cleans up two inconsistancies:
1. both doctests on the ::add methods were actually calling the const version.
2. on of the ::offset methods was missing a line of clarification.
part of https://github.com/rust-lang/rust/issues/139190
Implement ((un)checked_)exact_div methods for integers
tracking issue: #139911
I see that there might still be some bikeshedding to be done, so if people want changes to this implementation, I'm happy to make those. I did also see that there was a previous attempt at this PR (#116632), but I'm not sure why it got closed.
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`
This new parameter was requested in the btree_extract_if tracking issue: https://github.com/rust-lang/rust/issues/70530#issuecomment-2486566328
I attempted to follow the style used by `Vec::extract_if`.
Before:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
where
K: Ord,
F: FnMut(&K, &mut V) -> bool;
}
```
After:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
where
K: Ord,
R: RangeBounds<K>,
F: FnMut(&K, &mut V) -> bool;
}
```
Related: #70530
—
While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
