The lint for function calls was previously restricted to functions taking
exactly one argument. This was not documented.
Generalizing the lint to an arbitrary number of arguments in the function
call requires special casing some macro expansions from the standard
library. Macros such as `panic!()` or `assert_eq!()` exist since Rust
1.0.0, but modern stdlib expand those macros into calls to functions
introduced in later Rust versions. While it is desirable to lint code
inside macros, using MSRV-incompatible functions coming from `core`
in macro expansions has been special-cased to not trigger this lint.
Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a,
b)`. Those should not be linted either as the compiler is allowed to
use unstable function calls.
This feature was stabilized, so the FormatArgs lints should check if the MSRV of
the stabilization is met, rather than checking if the feature is enabled.
It is not possible to write a declarative macro, that produces an attribute w/o
an item attached to it. This means that the `check_item` will already insert the
span in the map, if it came from an expansion. So additionally checking if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()` call can
be completely removed.
Fixes#14303
The `looks_like_refdef` function was assuming the range was valid, this
just adds a check to ensure that is the case. It also works around a
subtraction underflow due to the same invalid range.
changelog: [`doc_nested_refdefs`]: Fix#14287 by avoiding invalid ranges
When the manually stripped entity receives a name as the first use
through a simple `let` statement, this name can be used in the generated
`if let Some(…)` expression instead of a placeholder.
Fix#14183
changelog: [`manual_strip`]: reuse existing identifier in suggestion
when possible
These method chains can be expressed concisely with `if`/`else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_else()` and
`then_some().unwrap_or_else()`
```rust
let mut tmp = vec![1, 2, 3];
for b in &mut tmp {
*b = !*b;
}
```
must not suggest the invalid `tmp.fill(!*b)`.
In addition, there is another commit which cleans up two function calls
with no effect.
Fix#14189
changelog: [`manual_slice_fill`]: ensure that the initialization
expression doesn't reference the iterator
- The name of an MSRV alias should describe its functionality, and it is
not appropriate for it to be the same as the name of the lint that uses
it.
- Additionally, while `manual_div_ceil` allows setting MSRV, this is not
correctly reflected in the configuration information.
changelog: none
Roses are red,
Biolets are blue,
A typo happened,
too late now
You might be asking,
what are Biolets now?
And to be honest,
I have no clue
---
The cat of this release is `Vera` nominated by @and-reas-se
<img height=500
src="https://github.com/user-attachments/assets/82e6fccc-1f6d-4d29-b6bb-0bd4f3584593"
alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
changelog: none
Lint `#[must_use]` attributes applied to methods in trait impls
The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This PR adds it to the unused `#[must_use]` lint, and cleans the extra attributes in portable-simd and Clippy.
fixes#13934
I modified the part for checking if the map is used so that it can check
field and index exprs.
changelog: [`map_entry`]: fix FP on struct member
In the case where `iter` is a `DoubleEndedIterator`, replacing a call to
`iter.last()` (which consumes `iter`) by `iter.next_back()` (which
requires a mutable reference to `iter`) cannot be done when `iter` is a
non-mutable binding which is not a mutable reference. When possible, a
local immutable binding is made into a mutable one.
Also, the applicability is switched to `MaybeIncorrect` and a note is
added to the output when the element types have a significant drop,
because the drop order will potentially be modified because
`.next_back()` does not consume the iterator nor the elements before the
last one.
Fix#14139
changelog: [`double_ended_iterator_last`]: do not trigger on
non-reference immutable receiver, and warn about possible drop order
change
`iter.last()` will drop all elements of `iter` in order, while
`iter.next_back()` will drop the non-last elements of `iter` when
`iter` goes out of scope since `.next_back()` does not consume its
argument.
When the transformation proposed by `double_ended_iterator_last` would
concern an iterator whose element type has a significant drop, a note is
added to warn about the possible drop order change, and the suggestion
is switched from `MachineApplicable` to `MaybeIncorrect`.
