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
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 😢
doc: make the usage of clippy.toml more clear
Added a subsection for it, and move it after `Allowing/denying lints` which is more frequently used.
fix https://github.com/rust-lang/rust-clippy/issues/9265
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
[`unnecessary_lazy_evaluations`] Do not suggest switching to early evaluation when type has custom `Drop`
fix#9427
changelog: [`unnecessary_lazy_evaluations`] Do not suggest switching to early evaluation when type has custom `Drop`
`Res::SelfTy` currently has two `Option`s. When the second one is `Some`
the first one is never consulted. So we can split it into two variants,
`Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res`
from 24 bytes to 12. This then shrinks `hir::Path` and
`hir::PathSegment`, which are the HIR types that take up the most space.
