Replace `in_macro` usage with `from_expansion`
changelog: none
Generally replace `in_macro(span)` with `span.from_expansion()`. If we're just trying to avoid expanded code, this seems more appropriate because any kind of expanded code is prone to false positives. One place I did not touch is `macro_use.rs`. I think this lint could use a rewrite so I moved `in_macro` there, the only place it is still used.
Move non_ascii_literal to restriction
It feels like the more apt category, since cases where you'd want it enabled would be pretty specific
changelog: Move [`non_ascii_literal`] to `restriction`
Prevent clippy::needless_lifetimes false positive in async function definition
Scan `OpaqueDef` bounds for lifetimes as well. Those `OpaqueDef` instances are generated while desugaring an `async` function definition.
This fixes#7893
changelog: Prevent [`clippy::needless_lifetimes`] false positive in `async` function definition
Fix manual_assert and match_wild_err_arm for `#![no_std]` and Rust 2021
Rust 2015 `std::panic!` has a wrapping block while `core::panic!` and Rust 2021 `std::panic!` does not. See rust-lang/rust#88919 for details.
Note that the test won't pass until clippy changes in rust-lang/rust#88860 is synced.
---
changelog: Fix [`manual_assert`] and [`match_wild_err_arm`] for `#![no_std]` and Rust 2021.
Fixes#7723
Unseparated literal suffix
Closes#7658
Since `literal_suffix` style is opinionated, we should disable by default and only enforce if it's stated as so.
changelog: [`unseparated_literal_suffix`] is renamed to `literal_suffix`, adds a new configuration `literal-suffix-style` to enforce a certain style writing literal_suffix. Possible values for `literal-suffix-style`: `"separated"`, `"unseparated"`
avoid linting `possible_truncation` on bit-reducing operations
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: avoid linting `possible_truncation` on bit-reducing operations
`unseparated_literal_suffix`
This commit adds a configuration `literal-suffix-style` to enforce a
specific style for unseparated_literal_suffix. The configuration accepts
two values:
- "separated"
enforce all literals to be written separately (e.g. `123_i32`)
- "unseparated"
enforce all literals to be written as unseparated (e.g. `123i32`)
Not specifying a value means that there is no preference on style and
any style should not be warned.
Disable "if_not_else" lints from firing on else-ifs
Fixes#7892
1. Convert `['if_not_else']` to `LateLintPass` and use `clippy_utils::is_else_clause` for checking.
2. Update tests.
changelog: [`if_not_else`] now ignores else if statements.
1. Convert IfNotElse to LateLintPass and use clippy_utils::is_else_clause for checking.
2. Handle the case where the span comes from desugaring.
3. Update tests.
Ignore references to type aliases in ptr_arg
Works using the fact that the hir path will point to a TyAlias, rather than being resolved to the underlying type
Fixes#7699
changelog: [`ptr_arg`] No longer lints references to type aliases
Add unit-hash lint
changelog: [`unit_hash`] Add lint for hashing unit values
This will lint for situations where the end user is attempting to hash a unit value (`()`), as the implementation in `std` simply [does nothing][impl]. Closes#7159 .
Example:
```rust
().hash(&mut state);
// Should (probably) be replaced with:
0_u8.hash(&mut state);
```
[impl]: a5f164faad/library/core/src/hash/mod.rs (L656)
Register the generated lints from `cargo dev new_lint`
How to register a lint was something that took me a couple reads to figure out, this will hopefully make that easier. It appends the created lint to the end of the list when running `cargo dev new_lint`
changelog: none
Fix `question_mark` FP on custom error type
Closes#7859#7840 aims to ignore `question_mark` when the return type is custom, which is [covered here](df65291edd/tests/ui/question_mark.rs (L144-L149)). But this fails when there is a call in conditional predicate
changelog: [`question_mark`] Fix false positive when there is call in conditional predicate
Clean up tests/ui/rename.rs
Part one of #7057, cleaning up `tests/ui/rename.rs`. `tests/ui/deprecated.rs` will be updated in a subsequent PR.
changelog: none
new lint: string-slice
This is a restriction lint to highlight code that should have tests containing non-ascii characters. See #6623.
changelog: new lint: [`string-slice`]
Fix `match_str_case_mismatch` on uncased chars
False positives would result because `char::is_lowercase` and friends will return `false` for non-alphabetic chars and alphabetic chars lacking case (such as CJK scripts). Care also has to be taken for handling titlecase characters (`Dz`) and lowercased chars with no uppercase equivalent (`ʁ`).
For example, when verifying lowercase:
* Check `!any(char::is_ascii_uppercase)` instead of `all(char::is_ascii_lowercase)` for ASCII.
* Check that `all(|c| c.to_lowercase() == c)` instead of `all(char::is_lowercase)` for non-ASCII
Fixes#7863.
changelog: Fix false positives in [`match_str_case_mismatch`] on uncased characters
Update `str` utils to prevent ICEs and FNs
This PR reworks some string handling for lints regarding enum naming. I hope the refactoring will prevent future ICEs and help with new bug free implementations.
It might be better to review this PR by going through the commits, as `clippy_utils::camel_case` was renamed to `clippy_utils::str_utils` and then changed further. GH sadly doesn't really make the changes that obvious 🙃
Not too much more to say. Have a nice day 🌞
---
Fixes: rust-lang/rust-clippy#7869
changelog: ICE Fix: [`enum_variant_names`] #7869
Don't mark for loop iter expression as desugared
We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
missing_safety_doc: Handle 'implementation safety' headers as well
We hit some FPs on this in `yoke`, it's somewhat normal to mark trait impl safety with "implementation safety". We could also broaden the check for headers which contain the word "safety" somehow, or split out impl safety stuff to only apply to traits.
changelog: handle 'implementation safety' headers in `missing_safety_doc`
Fix FP: no lint when cast is coming from `signum` method call for `cast_possible_truncation` lint
Fixes a FP when cast is coming from `signum` method call
fixes: #5395
changelog: [`cast_possible_truncation`] Fix FP when cast is coming from `signum` method call
Warn on structs with a trailing zero-sized array but no `repr` attribute
Closes#2868
changelog: Implement ``[`trailing_empty_array`]``, which warns if a struct is defined where the last field is a zero-sized array but there are no `repr` attributes. Zero-sized arrays aren't very useful in Rust itself, so such a struct is likely being created to pass to C code or in some other situation where control over memory layout matters. Either way, a `repr` attribute is needed.
FIx FP in `missing_safety_doc` lint
Fix FP where lint souldn't fire if any parent has `#[doc(hidden)]` attribute
fixes: #7347
changelog: [`missing_safety_doc`] Fix FP if any parent has `#[doc(hidden)]` attribute
The bug was dues to the constant bytes being compared instead of their
values. This meant that negative values were being treated as larger
than some positive values.
Fixes#7829
avoid `eq_op` in test code
Add a check to `eq_op` that will avoid linting in functions annotated with `#[test]`
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: avoid `eq_op` in test functions
Some "parenthesis" and "parentheses" fixes
"Parenthesis" is the singular (e.g. one `(` or one `)`) and "parentheses" is the plural (multiple `(` or `)`s) and this is not hard to mix up so here are some fixes for that.
Inspired by #89958
Add `format_in_format_args` and `to_string_in_format_args` lints
Fixes#7667 and #7729
I put these in `perf` since that was one of `@jplatte's` suggestions, and `redundant_clone` (which I consider to be similar) lives there as well.
However, I am open to changing the category or anything else.
r? `@camsteffen`
changelog: Add `format_in_format_args` and `to_string_in_format_args` lints
Do not expand macros in equatable_if_let suggestion
Fixes#7781
Let's use Hacktoberfest as a motivation to start contributing PRs myself again :)
changelog: [`equatable_if_let`]: No longer expands macros in the suggestion
Allow giving reasons for `disallowed_types`
Similar to #7609 but for the `disallowed_type` lint. The permitted form of configuration is the same as for `disallowed_methods`.
changelog: Allow giving reasons for [`disallowed_type`]
Fix FP in external macros for `mut_mut` lint
Fix FP in `mut_mut` lint when type is defined in external macros.
fixes: #6922
changelog: [`mut_mut`] Fix FP when type is defined in external macros
Refactor `clippy::match_ref_pats` to check for multiple reference patterns
fixes#7740
When there is only one pattern, to begin with, i.e. a single deref(`&`), then in such cases we suppress `clippy::match_ref_pats`.
This is done by checking the count of the reference pattern and emitting `clippy::match_ref_pats` when more than one pattern is present.
Removed certain errors in the `stderr` tests as they would not be triggered.
changelog: Refactor `clippy::match_ref_pats` to check for multiple reference patterns
Before this lint didn't trigger on macros. With rust-lang/rust#88175
this isn't enough anymore. In this PR a `WhileLoop` desugaring kind was
introduced. This overrides the span of expanded expressions when
lowering the while loop. So if a while loop is in a macro, the
expressions that it expands to are no longer marked with
`ExpnKind::Macro`, but with `ExpnKind::Desugaring`. In general, this is
the correct behavior and the same that is done for `ForLoop`s. It just
tripped up this lint.
Restriction lint for function pointer casts
The existing lints for function pointer casts cover the cases where a cast is non-portable or would result in truncation, however there's currently no way to forbid numeric function pointer casts entirely.
I've added a new lint `fn_to_numeric_cast_any`, which allows one to ban _all_ numeric function pointer casts, including to `usize`. This is useful if you're writing high-level Rust and want to opt-out of potentially surprising behaviour, avoiding silent bugs from forgotten parentheses, e.g.
```rust
fn foo() -> u32 {
10
}
fn main() {
let _ = foo as usize; // oops, forgot to call foo and got a random address instead!
}
```
~~I'm open to suggestions for the naming of the lint, because `fn_to_numeric_cast_any` is a bit clunky. Ideally I'd call this lint `fn_to_numeric_cast`, but that name is already taken for the more specific lint~~. We've stuck with `fn_to_numeric_cast_any` to avoid renaming the existing lint, or choosing a different name that's too generic (like `fn_cast`).
I'm also open to changing the suggestion behaviour, as adding parentheses is only one of many possible ways to fix the lint.
changelog: add ``[`fn_to_numeric_cast_any`]`` restriction lint
Make `shadow_reuse` suggestion less verbose
Closes#7764
Make `shadow_reuse` suggestion less verbose.
changelog: [`shadow_reuse`] does not warn shadowing statement
fix bug for large_enum_variants
Fix the discussion problem in the issue of https://github.com/rust-lang/rust-clippy/issues/7666#issuecomment-919654291
About the false positive problem of case:
```rust
enum LargeEnum6 {
A,
B([u8;255]),
C([u8;200]),
}
```
changelog: Fix largest_enum_variant wrongly identifying the second largest variant.
