We also update the documentation to note that the remediations are
different for `std` and `no_std` crates.
Signed-off-by: Joe Richey <joerichey@google.com>
Identical arguments on assert macro family
Lint when identical args are used on `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros.
Added to the lint `eq_op`.
Common functions added to `utils/higher.rs`
Fixes: #3574Fixes: #4694
changelog: Lint on identical args when calling `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros
Sync from rust
Fix rustc breakage by running:
```rust
git subtree push -P src/tools/clippy git@github.com:josephlr/rust-clippy sync-from-rust
```
and then adding a commit that runs `cargo dev fmt`
---
changelog: none
Expands `manual_memcpy` to lint ones with loop counters
Closes#1670
This PR expands `manual_memcpy` to lint ones with loop counters as described in https://github.com/rust-lang/rust-clippy/issues/1670#issuecomment-293280204
Although the current code is working, I have a couple of questions and concerns.
~~Firstly, I manually implemented `Clone` for `Sugg` because `AssocOp` lacks `Clone`. As `AssocOp` only holds an enum, which is `Copy`, as a value, it seems `AssocOp` can be `Clone`; but, I was not sure where to ask it. Should I make a PR to `rustc`?~~ The [PR]( https://github.com/rust-lang/rust/pull/73629) was made.
Secondly, manual copying with loop counters are likely to trigger `needless_range_loop` and `explicit_counter_loop` along with `manual_memcpy`; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggers `manual_memcpy`?
And, another thing I'd like to note is that `Sugg` adds unnecessary parentheses when expressions with parentheses passed to its `hir` function, as seen here:
```
error: it looks like you're manually copying between slices
--> $DIR/manual_memcpy.rs:145:14
|
LL | for i in 3..(3 + src.len()) {
| ^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[3..((3 + src.len()))].clone_from_slice(&src[..((3 + src.len()) - 3)])
```
However, using the `hir` function is needed to prevent the suggestion causing errors when users use bitwise operations; and also this have already existed, for example: `verbose_bit_mask`. Thus, I think this is fine.
changelog: Expands `manual_memcpy` to lint ones with loop counters
Preserve raw strs for: format!(s) to s.to_string() lint
fixes#6142
clippy::useless_format will keep the source's string (after converting {{ and }} to { and }) when suggesting a change from format!() to .to_string() usage. Ie:
| let s = format!(r#""hello {{}}""#);
| ^^^^^^^^^^^^^^^^^^^^^ help: consider using `.to_string()`: `r#""hello {}""#.to_string()`
changelog: [`useless_format`]: preserve raw string literals when no arguments to `format!()` are provided.
New lint: Recommend using `ptr::eq` when possible
This is based almost entirely on the code available in the previous PR #4596. I merely updated the code to make it compile.
Fixes#3661.
- [ ] I'm not sure about the lint name, but it was the one used in the original PR.
- [X] Added passing UI tests (including committed `.stderr` file)
- [X] `cargo test` passes locally
- [X] Executed `cargo dev update_lints`
- [X] Added lint documentation
- [X] Run `cargo dev fmt`
---
changelog: none
clippy_lints: Do not warn against Box parameter in C FFI
changelog: [`boxed_local`]: don't lint in `extern fn` arguments
Fixes#5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is C.
unnecessary sort by: avoid dereferencing the suggested closure parameter
This change tries to simplify the solution for problematic cases but is less restrictive than #6006.
* We can't dereference shared references to non-Copy types, so the new suggestion does not do that. Note that this implies that the suggested closure parameter will be a reference.
* We can't take a reference to the closure parameter in the returned key, so we don't lint in those cases. This can happen either because the key borrows from the parameter (e.g. `|a| a.borrows()`), or because we suggest `|a| Reverse(a)`. If we did we would hit this error:
```
error: lifetime may not live long enough
--> /home/ebroto/src/ebroto-clippy/tests/ui/unnecessary_sort_by.fixed:19:25
|
19 | vec.sort_by_key(|b| Reverse(b));
| -- ^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
| ||
| |return type of closure is Reverse<&'2 isize>
| has type `&'1 isize`
error: aborting due to previous error
```
Note that Clippy does not currently have the (MIR-based) machinery necessary to check that what is borrowed is actually the closure parameter.
changelog: [`unnecessary_sort_by`]: avoid dereferencing the suggested closure parameter
Fixes#6001
Don't emit a lint for the suggestion leading to errors in `needless_range_loop`
Fix#5945
changelog: Don't emit a lint for the suggestion leading to errors in `needless_range_loop`
New Lint: disallowed_method
Fixes https://github.com/rust-lang/rust-clippy/issues/6073
I added a `disallowed_method` lint that works similar to `blacklisted_name`, e.g allows config-defined disallowed method calls.
This lint allows advanced users to patch in undesired method calls for specific projects. It basically uses the DefId of method calls and matches it to parsed strings. Is there an alternative approach that could use more easily digestible configuration strings?
All tests pass as expected except for a linting error on `ui/redundant_pattern_matching_option`, which I am not sure how to resolve since I don't think I changed anything affecting it.
changelog: Add disallowed_method lint to warn on user-defined method calls
Fix FP in `print_stdout`
Fix#6041
This lint shouldn't be emitted in `build.rs` as `println!` and `print!` are used for the build script.
changelog: none
