Fix several issues with `manual_is_multiple_of`
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing
with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)`
might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
Those fixes have required increasing the precision of type certainty
determination in the two first patches.
Fixesrust-lang/rust-clippy#15203Fixesrust-lang/rust-clippy#15204
changelog: [`manual_is_multiple_of`]: fix various false positive
Fix some cases for `approx_const`:
- When the literal has more digits than significant ones, the string
comparison wasn't working
- When numbers are formatted in a non trivial way (with leading `0`s or
using `_`) the lint now finds those cases
changelog: [`approx_const`]: Fix when used over overly precise literals
and non trivially formatted numerals
Fixesrust-lang/rust-clippy#15194
<strike>blocked on rust-lang/rust-clippy#15073</strike>
Lint method calls inside `map_or` too, so for this, lint will be showed:
```rust
Some(4).map_or("asd".to_string().len() as i32, f);
```
previously it worked only for:
```rust
Some(4).map_or(slow_fun(), f);
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=bfcda42a6af446e69bc883a8b45eb13c
Sorry for multiple `or_fun_call` PRs.
changelog: [`or_fun_call`]: lint method calls inside map_or first arg
Closesrust-lang/rust-clippy#15063
----
changelog: [`op_ref`]: fix wrongly showed macro definition in
suggestions
changelog: [`needless_bool_assign`]: fix missing curlies when on else if
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit`
was ignored, despite the fact that its value should determine the value
of the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
changelog: [`manual_is_variant_and`]: fix inverted suggestions that
could lead to code with different semantics
Fixesrust-lang/rust-clippy#15202
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15206#issuecomment-3034006613)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
Propose to replace `x.map_or(false, |y| y == z)` by `x == Some(z)` only
if `x` is not adjusted. Otherwise, the type of `x` in the comparaison
may not be the expected one, as it may be the product of an auto-deref.
changelog: [`unnecessary_map_or`]: do not propose to replace the
`map_or` call by a comparaison if types wouldn't be correct
Fixesrust-lang/rust-clippy#15180
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit` was
ignored, despite the fact that its value should determine the value of
the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
<strike>build on top of rust-lang/rust-clippy#15071</strike>
This also adds ability to lint Option/Result::and method. Yes, this is
not `or` method, but uses the same eager/lazy linting logic. Should i
update lint description to list all checked structs/methods?
changelog: [`or_fun_call`]: lint Option/Result::and
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that
can be used as a return value. A new
`potential_return_of_enclosing_body()` utility function has been made to
represent the fact that an expression might be directly returned from
its enclosing body.
changelog: [`return_and_then`]: prevent false positives in case of a
partially used expression
Fixesrust-lang/rust-clippy#15111Fixesrust-lang/rust-clippy#14927
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15115#issuecomment-2996222332)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
This commit also adds more test cases, which already worked but were
mentioned in the issue.
Fixesrust-lang/rust-clippy#9939
changelog: [`manual_let_else`]: correctly handle binding subpattern with
unused name
Fixes: rust-lang/rust-clippy#14897, rust-lang/rust-clippy#10015
This is not a perfect solution, but it fixes the issue. Happy to discuss
further with the clippy team.
This PR refines check_mul_add to avoid false positives on ambiguous
float types (e.g., f32 vs f64). It improves type detection and ensures
mul_add is only suggested when the type is clear.
Changes:
- Improved detection of ambiguous float types
- Refined mul_add suggestion logic
- Added tests for ambiguous cases
## Example
Before this change, expressions like:
```rust
let x = 1.0; // ambiguous type
let _ = x * 2.0 + 0.5; // could incorrectly suggest mul_add
```
----
changelog: [`suboptimal_flops`]: improve handling of ambiguous float
types in mul_add suggestions
Hi,
I noticed that the lint
[neg_multiply](https://rust-lang.github.io/rust-clippy/master/index.html#neg_multiply)
generates bad code when we call a method on the expression.
Consider `((a.delta - 0.5).abs() * -1.0).total_cmp(&1.0)`. Currently
this would be changed by clippy to `-(a.delta - 0.5).abs()
.total_cmp(&1.0)` - which does not compile because we are trying to
negate an ordering enum - but what we really want is `(-(a.delta -
0.5).abs()).total_cmp(&1.0)`.
This PR fixes this.
changelog: [`neg_multiply`] does not remove parenthesis anymore if a
method is being called on the affected expression
NOTE: This is the first time I am contributing to clippy or the rust
repo in general. So I am not sure whether my approach to fixing this
issue is goo, if there are better solutions or if I missed something.
Thanks & hope you have a good day,
Dario
Fixesrust-lang/rust-clippy#9583
When a closure with no parameters is called immediately after being
defined, clippy can now suggest replacing the entire expression with
just the closure's body.
----
changelog: [`redundant_closure_call`]: add fixes for closures with block
While `expr as T` can be removed as a statement if `expr` has no
side-effect, the `as T` part alone cannot be removed if the type of
`expr` would be ambiguous without the cast.
changelog: [`unnecessary_operation`]: do not remove casts if they are
useful to type the expression
Fixesrust-lang/rust-clippy#15173
- `&a % &b == 0` compiles, but requires dereferencing `b` when
replacing with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain,
`a.is_multiple_of(b)` might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
changelog: none
This tries to make progress on
https://github.com/rust-lang/rust/issues/78717 by using the ui_test
dependency handling instead of linking in the dependencies of clippy
itself with the tests. This partially reverts
https://github.com/rust-lang/rust-clippy/pull/11045. However, we still
use the old style of dealing with dependencies for clippy's own crates
and the "internal" tests, as otherwise those would get rebuilt which
takes too long.
