new `implicit_saturating_add` lint
This fixes#9393
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[x] Followed [lint naming conventions][lint_naming]
- \[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: add [`manual_saturating_add`] lint
let `upper_case_acronyms` check the enum name
Signed-off-by: TennyZhuang <zty0826@gmail.com>
Fix#9579
changelog: [`upper_case_acronyms`]: check the enum name
Replace `expr_visitor` with `for_each_expr`
This is a minor change which uses `ControlFlow` rather than a boolean. This also runs the visitor rather than returning the visitor, which results in a small readability win as well.
changelog: None
Fix and improve `match_type_on_diagnostic_item`
This extracts the fix for the lint out of #7647. There's still a couple of other functions to check, but at least this will get lint working again.
The two added util functions (`is_diagnostic_item` and `is_lang_item`) are needed to handle `DefId` for unit and tuple struct/variant constructors. The `rustc_diagnostic_item` and `lang` attributes are attached to the struct/variant `DefId`, but most of the time they are used through their constructors which have a different `DefId`. The two utility functions will check if the `DefId` is for a constructor and switch to the associated struct/variant `DefId`.
There does seem to be a bug on rustc's side where constructor `DefId`s from external crates seem to be returning `DefKind::Variant` instead of `DefKind::Ctor()`. There's a workaround put in right.
changelog: None
In order to switch `clippy::uninlined_format_args` from pedantic to
style, all existing tests must not raise a warning. I did not want to
change the actual tests, so this is a relatively minor change that:
* add `#![allow(clippy::uninlined_format_args)]` where needed
* normalizes all allow/deny/warn attributes
* all allow attributes are grouped together
* sorted alphabetically
* the `clippy::*` attributes are listed separate from the other ones.
* deny and warn attributes are listed before the allowed ones
changelog: none
Remove unused `.fixed` files, only run asm_syntax doctests on x86
Two small changes, removes some unused `.fixed` and makes `clippy_lints` doctests pass on non x86 arches
changelog: none
* Check for `const`s and `static`s from external crates
* Check for `LangItem`s
* Handle inherent functions which have the same name as a field
* Also check the following functions:
* `match_trait_method`
* `match_def_path`
* `is_expr_path_def_path`
* `is_qpath_def_path`
* Handle checking for a constructor to a diagnostic item or `LangItem`
let unnecessary_cast work for trivial non_literal expressions
Signed-off-by: TennyZhuang <zty0826@gmail.com>
---
changelog: [`unnecessary_cast`]: fix for trivial non_literal expressions
Fixes#9562
[`unnecessary_cast`] add parenthesis when negative number uses a method
fix#9563
The issue was probably introduced by 90fe3bea52
changelog: [`unnecessary_cast`] add parenthesis when negative number uses a method
r? llogiq
use `is_integer_literal` more
I noticed that we have the `is_integer_literal` function in our `clippy_utils`, yet almost everywhere people still match int literal expressions manually. So I searched for instances to replace and shorten the code a bit.
---
changelog: none
lint nested patterns and slice patterns in `needless_borrowed_reference`
Now lints in positions other than top level, e.g. `Some(&ref a)`. Or patterns are excluded as that can cause issues
Slice patterns of `ref`s are now linted, e.g. `&[ref a, ref b]`. An easy one to walk into as you might expect that to match against a slice you should use `&[]`, then to get around a `cannot move out of type [T]` error you apply a `ref`
changelog: [`needless_borrowed_reference`]: lint nested patterns and slice patterns
Fix sorting in ` cargo dev update_lints` script
changelog: none
The old code cloned and sorted `usable_lints` into `sorted_usable_lints`, but then failed to do anything with `sorted_usable_lints`.
This was discovered by my new `collection_is_never_read` lint (#9267) that I'm working on!
Fix: I renamed the sorted vector to `usable_lints`. Therefore it now gets used where the unsorted one was used previously.
Implement `manual_clamp` lint
Fixes#9477Fixes#6751
Identifies common patterns where usage of the `clamp` function would be more succinct and clear, and suggests using the `clamp` function instead.
changelog: [`manual_clamp`]: Implement manual_clamp lint
This lint detects calls to a `&self`-taking `as_ptr` method, where
the result is then immediately cast to a `*mut T`. Code like this
is probably invalid, as that pointer will not have write permissions,
and `*mut T` is usually used to write through.
avoid doc-link-with-quotes in code blocks
This fixes#8961 by moving the lint into the docs code, thus being able to re-use the pulldown-cmark parser and simplifying the code.
---
changelog: none
rustc_tool_utils: bump version in anticipation of a new release
cc https://github.com/rust-lang/rust-clippy/issues/9553
After this is merged, I will publish the 0.2.1 version to crates.io, and make another PR that switches clippy to use the dependency from crates.io.
The source can still be kept in the clippy repo though imo.
This will allow miri and clippy to "share" the crate in the rustc repo once they both depend on it.
reopen of #9561
changelog: release `rustc_tools_util` on `Crates.io`.
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
