List configuration values can now be extended instead of replaced
I've seen some `clippy.toml` files, that have a few additions to the default list of a configuration and then a copy of our default. The list will therefore not be updated, when we add new names. This change should make it simple for new users to append values instead of replacing them.
I'm uncertain if the documentation of the `".."` is apparent. Any suggestions are welcome. I've also check that the lint list displays the examples correctly.
<details>
<summary>Lint list screenshots</summary>
</details>
---
changelog: enhancement: [`doc_markdown`]: Users can now indicate, that the `doc-valid-idents` should extend the default and not replace it
changelog: enhancement: [`blacklisted-name`]: Users can now indicate, that the `blacklisted-names` should extend the default and not replace it
Closes: #8877
That's it. Have a fantastic weekend to everyone reading this. Here is a cookie 🍪
improve [`for_loops_over_fallibles`] to detect the usage of iter, iter_mut and into_iterator
fix#6762
detects code like
```rust
for _ in option.iter() {
//..
}
```
changelog: Improve [`for_loops_over_fallibles`] to detect `for _ in option.iter() {}` or using `iter_mut()` or `into_iterator()`.
fix(manual_find_map and manual_filter_map): check clone method
close#8920
Added conditional branching when the clone method is used.
Thank you in advance.
---
changelog: check `clone()` and other variant preserving methods in [`manual_find_map`] and [`manual_filter_map`]
When setting suggestion for significant_drop_in_scrutinee, add suggestion for MoveAndClone for non-ref
When trying to set the current suggestion, if the type of the expression
is not a reference and it is not trivially pure clone copy, we should still
trigger and emit a lint message. Since this fix may require cloning an
expensive-to-clone type, do not attempt to offer a suggested fix.
This change means that matches generated from TryDesugar and AwaitDesugar
would normally trigger a lint, but they are out of scope for this lint,
so we will explicitly ignore matches with sources of TryDesugar or
AwaitDesugar.
changelog: Update for ``[`significant_drop_in_scrutinee`]`` to correctly
emit lint messages for cases where the type is not a reference *and*
not trivially pure clone copy.
changelog: [`significant_drop_in_scrutinee`]: No longer lint on Try `?`
and `await` desugared expressions.
remove `large_enum_variant` suggestion for `Copy` types
Replaces the (erroneous) suggestion on `large_enum_variant` for `Copy` types by a note. This fixes#8894.
---
changelog: none
Set correct `ParamEnv` for `derive_partial_eq_without_eq`
fixes#8867
changelog: Handle differing predicates applied by `#[derive(PartialEq)]` and `#[derive(Eq)]` in `derive_partial_eq_without_eq`
new lint: `borrow_deref_ref`
changelog: ``[`borrow_deref_ref`]``
Related pr: #6837#7577
`@Jarcho` Could you please give a review?
`cargo lintcheck` gives no false negative (but tested crates are out-of-date).
TODO:
1. Not sure the name. `deref_on_immutable_ref` or some others?
Fix `manual_range_contains` false negative with chains of `&&` and `||`
Fixes#8745
Since the precedence for `&&` is the same as itself the HIR for a chain of `&&` ends up with a right skewed tree like:
```
&&
/ \
&& c2
/ \
... c1
```
So only the leftmost `&&` was actually "fully" checked, the top level was just `c2` and `&&` so the `manual_range_contains` lint won't apply. This change makes it also check `c2` with `c1`.
There's a bit of a hacky solution in the [second commit](257f09776a) to check if the number of open/closing parens in the snippet match. This is to prevent a case like `((x % 2 == 0) || (x < 0)) || (x >= 10)` from offering a suggestion like `((x % 2 == 0) || !(0..10).contains(&x)` which now won't compile.
Any suggestions for that paren hack welcome, kinda new to working on this so not too sure about possible solutions :) it's weird because I don't know how else to check for parens in HIR considering they're removed when lowering AST.
changelog: Fix [`manual_range_contains`] false negative with chains of `&&` and `||`
Don't lint `useless_transmute` on types with erased regions
fixes#6356fixes#3340fixes#2906
This should get a proper fix at some point, but this at least gets the lint running on some types.
cc #5343
changelog: Don't lint `useless_transmute` on types with erased regions
`cast_abs_to_unsigned`: do not remove cast if it's required
Fixes#8873
If `iX` is not cast to `uX` then keep the cast rather than removing it
changelog: [`cast_abs_to_unsigned`]: do not remove cast if it's required
needless_late_init: fix ICE when all branches return the never type
Fixes#8911
When the assignment is done in a match guard or the if condition and all of the branches return the never type `assignment_suggestions` would return an empty `Vec` which caused the ICE. It now returns `None` in that scenario
Also moves some tests to the top of the file
changelog: ICE Fixes: [`needless_late_init`] #8911
Fix `[use_self]` false negative with on struct and tuple struct patterns
fixes#8845
changelog: Triggered the warning for ``[`use_self`]`` on `TupleStruct` and `Struct` patterns, whereas currently it's only triggered for `Path` patterns
add doc_link_with_quotes lint
I'm not sure about wording, it seems OK to me but happy to change if other people have better ideas
closes#8383
---
changelog: add [`doc_link_with_quotes`] lint
Check `.fixed` paths' existence in `run_ui`
This PR adds a test to check that there exists a `.fixed` file for every `.stderr` file in `tests/ui` that mentions a `MachineApplicable` lint. The test leverages `compiletest-rs`'s `rustfix_coverage` option.
I tried to add `.fixed` files where they appeared to be missing. However, 38 exceptional `.rs` files remain. Several of those include comments indicating that they are exceptions, though not all do. Apologies, as I have not tried to associate the 38 files with GH issues. (I think that would be a lot of work, and I worry about linking the wrong issue.)
changelog: none
Fix `empty_line_after_outer_attribute` false positive
This PR fixes a false positive in `empty_line_after_outer_attribute`.
Here is a minimal example that trigger the FP:
```rust
#[derive(clap::Parser)]
#[clap(after_help = "This ia a help message.
You're welcome.
")]
pub struct Args;
```
changelog: PF: [`empty_line_after_outer_attribute`]: No longer lints empty lines in inner string values.
Introduce `allow-dbg-in-tests` config value
related to: Issue #8758, PR https://github.com/rust-lang/rust-clippy/pull/8838
changelog: Introduced `allow-dbg-in-tests` config value. [dbg_macro] does not allow `dbg!` in test code by default.
