It seems it returns true when *no* constraints are found, opposite to
the expected behavior of the function name.
This commit reverses condition as the name suggests.
It modernizes the coding style of the crate intrinsic-test by fixing
Clippy warnings.
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 36/36
It modernizes the coding style of the crate stdarch_examples (an example
"connect5") by fixing Clippy warnings (except clippy::manual_range_contains
in which "fixing" the warning will complicate the code).
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 6/6
It modernizes the coding style of the crate stdarch-verify by dealing
with Clippy warnings (allows clippy::collapsible_if but review may be
required for later changes).
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 4/4
It modernizes the coding style of the crate stdarch-test by fixing
Clippy warnings.
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 1/1
It modernizes the coding style of the crate stdarch-gen-loongarch by
fixing Clippy warnings.
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 1/1
Confirmed that the exact same code will be generated (note that,
generated.rs in the repository is *not* an exact output but some spaces
removed).
It modernizes the coding style of the crate stdarch-gen-arm by fixing
Clippy warnings (except clippy::{collapsible_if,obfuscated_if_else} that
might make the program look worse as a result of "fixing" warnings).
Clippy: rust version 1.89.0-nightly (6f6971078 2025-05-28)
Number of Fixed Warnings: 84/84
Note:
Rust Analyzer double counts one of the Clippy warnings so it reduces
85 warnings (as reported by the Rust Analyzer).
This commit also applies similar technique used to resolve Clippy
warnings but also simplifies identifier name formatting and makes
reading easier.
Confirmed that the exact same code will be generated.
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
As the author confirmed as in:
<https://lists.infradead.org/pipermail/linux-riscv/2025-May/070844.html>,
runtime detection of the Zicntr extension (as in the Linux kernel 6.15)
is currently (and technically) redundant on the current base IMA behavior
(although can be meaningful if new base behavior is added).
This commit implies the Zicntr extension from the base IMA behavior.
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.
