Starting with Rust version 1.82.0, the compiler generates similar code
with and without the `with_ref` cfg:
```rust
fn f(x: impl IntoIterator<Item = String>) {
for y in x { println!("{y}"); }
}
fn main() {
#[cfg(with_ref)]
let a = ["foo", "bar"].iter().map(|&s| s.to_string());
#[cfg(not(with_ref))]
let a = ["foo", "bar"].iter().map(|s| s.to_string());
f(a);
}
```
The generated code is strictly identical with `-O`, and identical modulo
some minor reordering without.
changelog: [`inefficient_to_string`]: do not trigger for Rust ≥ 1.82.0
Starting with Rust version 1.82.0, the compiler generates similar code with
and without the `with_ref` cfg:
```rust
fn f(x: impl IntoIterator<Item = String>) {
for y in x { println!("{y}"); }
}
fn main() {
#[cfg(with_ref)]
let a = ["foo", "bar"].iter().map(|&s| s.to_string());
#[cfg(not(with_ref))]
let a = ["foo", "bar"].iter().map(|s| s.to_string());
f(a);
}
```
The generated code is strictly identical with `-O`, and identical modulo
some minor reordering without.
This might be due to a low edition (< 2024) or too low a MSRV. In this
case, we will suggest only `match`.
Fixesrust-lang/rust-clippy#15744
changelog: [`unnecessary_unwrap`]: do not suggest using `if let` chains
if this is not supported with the current edition or MSRV
changelog:[`collapsible_if`]: Do not suggest using `if let` if this is
not supported with the current edition or MSRV
fixes https://github.com/rust-lang/rust-clippy/issues/13734
This PR renames `unchecked_duration_subtraction` lint to
`unchecked_time_subtraction` and extends it to include `Duration -
Duration` operations. Previously, it was only `Instant - Duration`.
`Duration - Duration` is a common operation which may panic in the same
way.
Note: This is my first clippy PR, feedback is appreciated.
changelog: [`unchecked_time_subtraction`]: renamed from
`unchecked_duration_subtraction`, extend lint to include subtraction of
a `Duration` with a `Duration`
Check that all configuration options reference existing lints. This was
prompted by a discussion on a PR review in which a non-detected
discrepancy was introduced.
While adding and testing this test, references to two non-existing lints
were removed.
This test doesn't run as part of the rustc test suite.
changelog: none
JetBrains has transitioned from the IntelliJ Rust plugin to RustRover as
their dedicated Rust IDE. This updates the documentation to reflect this
change while maintaining backward compatibility with the existing `cargo
dev setup intellij` command.
Changes:
- Replace IntelliJ Rust references with RustRover in CONTRIBUTING.md
- Update links to point to official RustRover homepage
- Update development guide in book/src/development/basics.md
- Keep existing command names for backward compatibility
**Question**: Do we also need to change the `intellij` command to
`rustrover`?
fixesrust-lang/rust-clippy#15406
changelog: Update CONTRIBUTING.md to reference RustRover instead of
deprecated IntelliJ Rust
JetBrains has transitioned from the IntelliJ Rust plugin to RustRover
as their dedicated Rust IDE. This updates the documentation to reflect
this change while maintaining backward compatibility with the existing
cargo dev setup intellij command.
Changes:
- Replace IntelliJ Rust references with RustRover in CONTRIBUTING.md
- Update links to point to official RustRover homepage
- Update development guide in book/src/development/basics.md
- Keep existing command names for backward compatibility
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.
This PR announces the feature freeze period talked about in
https://github.com/rust-lang/rust-clippy/issues/14364
1. Add the page to the book
2. Modify the in-Github templates.
3. The third commit (to be squashed into the first) rolls the date
mentioned 6 weeks (so, starting on May 9th and ending on August 20th).
This gives us a comfortable buffer to make choices for this period.
We have a pending discussion on the #14364. So having some more time to
make choices is very nice. I'm also preparing a Github action for
detecting new lints and posting a comment about the feature freeze
(being worked on in another branch)
Something I'd like comment on is the date formatting. I'm not sure if
"May 9th to the first of August" is the correct way of writing this
information in a book 😅.
changelog: Announce the feature freeze from May 9th to the first of
August
`is_trait_method` is not even used in this codeblock, whereas
`implements_trait` is used but not imported
(not sure if this is _actually_ a "changelog: none", since the
documentation is at least contributor-facing)
changelog: none
Fixes
https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Ambiguous.20default.20value.20for.20.60trivial-copy-size-limit.60
The current situation is
| Target width | `trivial-copy-size-limit`|
|--------|--------|
| 8-bit | 2 |
| 16-bit | 4 |
| 32-bit | 8 |
| 64-bit | 8 |
~~Since practically speaking it's almost always 8, let's go with that as
the unconditional default to make it easier to understand~~
Now defaults to `target_pointer_width`
changelog: [`trivial-copy-size-limit`] now also defaults to the size of
a target pointer (unchanged for 64-bit targets)
The first commit fixesrust-lang/rust-clippy#14802: when a slice is
directly present, it must be dereferenced (instead of referenced -1
times) before being passed to `mem::size_of_val()`.
The second commit triggers the lint in a `const` contact when MSRV ≥
1.85.
changelog: [`manual_slice_size_computation`]: fix ICE in suggestion to
efficiently compute the size of a slice, and trigger the lint in `const`
context as well
fixes#14413
add allow_unused config to missing_docs_in_private_items for underscored
field
changelog: [`missing_docs_in_private_items`]: add allow_unused config to
missing_docs_in_private_items for underscored field
Explaination (quoted from the issue's author): When writing structures
that must adhere to a specific format (such as memory mapped I/O
structures) there are inevitably fields that are "reserved" by
specifications and thus need no documentation. In cases where private
docs are preferred but reserved fields need no explanation, having to
#[allow/expect] this lint removes the ability to check for otherwise
used fields' documentation.
Jason Newcomb