adding condition for map_clone message
This PR fixes the message about `map_clone`.
if msrv >= 1.36, the message is correct.
```bash
$ cat main.rs
fn main() {
let x: Vec<&i32> = vec![&1, &2];
let y: Vec<_> = x.iter().map(|i| *i).collect();
println!("{:?}", y);
}
$ cargo clippy
warning: you are using an explicit closure for copying elements
--> main.rs:3:20
|
3 | let y: Vec<_> = x.iter().map(|i| *i).collect();
| ^^^^^^^^^^^^^^^^^^^^ help: consider calling the dedicated `copied` method: `x.iter().copied()`
|
= note: `#[warn(clippy::map_clone)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_clone
warning: `test` (build script) generated 1 warning
warning: `test` (bin "test") generated 1 warning (1 duplicate)
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
```
but, if msrv < 1.36, the suggestion is `cloned`, but the message is `copying`.
```bash
$ cat clippy.toml
msrv = "1.35"
$ cargo clippy
warning: you are using an explicit closure for copying elements
--> main.rs:3:20
|
3 | let y: Vec<_> = x.iter().map(|i| *i).collect();
| ^^^^^^^^^^^^^^^^^^^^ help: consider calling the dedicated `cloned` method: `x.iter().cloned()`
```
I think the separation of messages will make it more user-friendly.
thank you in advance.
changelog: Fixed a message in map_clone.
New lint `is_digit_ascii_radix`
Closes#6399
changelog: Added [`is_digit_ascii_radix`]: recommend `is_ascii_digit()` or `is_ascii_hexdigit()` in place of `is_digit(10)` and `is_digit(16)`
Fix subtraction overflow in `cast_possible_truncation`
changelog: Fix false negative due to subtraction overflow in `cast_possible_truncation`
I *think* a false negative is the worst that can happen from this
Don't lint various match lints when expanded by a proc-macro
fixes#4952
As always for proc-macro output this is a hack-job of a fix. It would be really nice if more proc-macro authors would set spans correctly.
changelog: Don't lint various lints on proc-macro output.
Fix `same_functions_in_if_condition` FP
fixes#8139
changelog: Don't consider `Foo<{ SomeConstant }>` and `Foo<{ SomeOtherConstant }>` to be the same, even if the constants have the same value.
Remove overlap between `manual_split_once` and `needless_splitn`
changelog: Remove overlap between [`manual_split_once`] and [`needless_splitn`]. Fixes some incorrect `rsplitn` suggestions for [`manual_split_once`]
Things that can trigger `needless_splitn` no longer trigger `manual_split_once`, e.g.
```rust
s.[r]splitn(2, '=').next();
s.[r]splitn(2, '=').nth(0);
s.[r]splitn(3, '=').next_tuple();
```
Fixes some suggestions:
```rust
let s = "should not match";
s.rsplitn(2, '.').nth(1);
// old -> Some("should not match")
Some(s.rsplit_once('.').map_or(s, |x| x.0));
// new -> None
s.rsplit_once('.').map(|x| x.0);
s.rsplitn(2, '.').nth(1)?;
// old -> "should not match"
s.rsplit_once('.').map_or(s, |x| x.0);
// new -> early returns
s.rsplit_once('.')?.0;
```
ignore `&x | &y` in unnested_or_patterns
replacing it with `&(x | y)` is actually more characters
Fixes#6973
changelog: [`unnested_or_patterns`] ignore `&x | &y`, nesting would result in more characters
Add a lint to detect cast to unsigned for abs() and suggest unsigned_…
…abs()
changelog: Add a [`cast_abs_to_unsigned`] that checks for uses of `abs()` that are cast to the corresponding unsigned integer type and suggest to replace them with `unsigned_abs()`.
Fix `as_deref_mut` false positives in `needless_option_as_deref`
Also moves it into `methods/`
Fixes#7846Fixes#8047
changelog: [`needless_option_as_deref`]: No longer lints for `as_deref_mut` on Options that cannot be moved
supersedes #8064
fix FP in lint `[needless_match]`
fixes: #8542fixes: #8551fixes: #8595fixes: #8599
---
changelog: check for more complex custom type, and ignore type coercion in [`needless_match`]
Suggest from_utf8_unchecked in const contexts
Unfortunately I couldn't figure out how to check whether a given expression is in an `unsafe` context or not, so I just unconditionally emit the wrapping `unsafe {}` block in the suggestion. If there is an easy way to get it to work better then I would love to hear it.
changelog: Suggest `from_utf8_unchecked` instead of `from_utf8` in const contexts for ``[`transmute_bytes_to_str`]``
refs: #8379
Fix unnecessary_cast suggestion for type aliasses
Fix#6923. The [`unnecessary_cast`] lint now will skip casting to non-primitive type.
changelog: fix lint [`unnecessary_cast `]
`indexing_slicing` should not fire if a valid array index comes from a constant function that is evaluated at compile-time
fix#8348
changelog: [`indexing_slicing`] fewer false positives in `const` contexts and with `const` indices
fix misspelling in diagnostic message of `bytes_nth`
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: fix misspelling in diagnostic message in ``[`bytes_nth`]``
Run fmt test before compile-test/dogfood
I seem to always forget to run `cargo dev fmt` before doing a test. This lets it fail fast rather than going through the much longer compile-test/dogfood tests first
changelog: none
Rework `undocumented_unsafe_blocks`
fixes: #8264fixes: #8449
One thing came up while working on this. Currently comments on the same line are supported like so:
```rust
/* SAFETY: reason */ unsafe {}
```
Is this worth supporting at all? Anything other than a couple of words doesn't really fit well.
edit: [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/.60undocumented_unsafe_blocks.60.20same.20line.20comment)
changelog: Don't lint `undocumented_unsafe_blocks` when the unsafe block comes from a proc-macro.
changelog: Don't lint `undocumented_unsafe_blocks` when the preceding line has a safety comment and the unsafe block is a sub-expression.
add `empty_structs_with_brackets`
<!-- Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change. Also, it's helpful for us that
the lint name is put into brackets `[]` and backticks `` ` ` ``,
e.g. ``[`lint_name`]``.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[ ] Followed [lint naming conventions][lint_naming]
- \[ ] Added passing UI tests (including committed `.stderr` file)
- \[ ] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[ ] Run `cargo dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR.
--
*Please write a short comment explaining your change (or "none" for internal only changes)*
-->
Closes#8591
I'm already sorry for the massive diff 😅
changelog: New lint [`empty_structs_with_brackets`]
Remove deps
This remove both `regex` and `cargo_metadata` as dependencies making `clippy_dev` compile ~3x faster (~46s -> ~16s locally). `cargo_metadata` was used to extract the `version` field from `Cargo.toml`, which is done trivially without that. `regex` was used to parse `define_clippy_lint` in `update_lints` which is now done using `rustc_lexer`. This isn't any simpler, but it compiles ~15s faster and runs ~3x faster (~2.1s -> ~0.7s locally).
The next biggest offenders to compile times are `clap` and `winapi` on windows. `clap` could be removed, but re-implementing enough is probably more work than it's worth. `winapi` is used by `opener` and `walkdir` so it's stuck there.
changelog: none
Handle relative paths in module_files lints
The problem being that when clippy is run in the project's directory `lp` would be a relative path, this wasn't caught by the tests as there `lp` is an absolute path. Being a relative path it did not start with `trim_src_path` and so was ignored
Also allowed the removal of some `.to_os_string`/`.to_owned`s
changelog: Fixes [`self_named_module_files`] and [`mod_module_files`] not linting
Fixes#8123, cc `@DevinR528`