Two optimizations have been done when checking for the context in which
to apply the lint:
- Checking for the mere presence of comments does not require building a
`String` with the comment to then check if it is empty and discard it.
- Checking for the presence of comment can be done after we have checked
that we do have a `if` construct that we intend to lint instead of for
every expression.
This limits repeated lookups in pre-checks (to determine if a MSRV
should be checked), especially when those require locking up an
interner:
- The `core` crate is looked up once when creating the lint, instead of
comparing the crate name with `sym::core` at every check.
- `span.ctxt().outer_expn_data()` is lookup up only once.
changelog: none
r? blyxyas
This limits repeated lookups in pre-checks (to determine if a MSRV
should be checked), especially when those require locking up
an interner:
- The `core` crate is looked up once when creating the lint, instead of
comparing the crate name with `sym::core` at every check.
- `span.ctxt().outer_expn_data()` is lookup up only once.
changelog: [`collapsible_else_if`]: fix suggestion when inner `if` as
wrapped in parentheses
changelog: [`collapsible_if`]: fix suggestion when inner `if` as wrapped
in parentheses
fixes https://github.com/rust-lang/rust-clippy/issues/15303
I'm sure this is a bit dirty, but don't currently see a better way.
The `unnecessary_sort_by` lint displays different method names in
message and suggestion, which is a bit confusing.
Also got a question about `UNNECESSARY_SORT_BY` lint definition. Should
we extend its message to also cover *_unstable_* methods?
changelog: [`unnecessary-sort-by`]: sort method consistency in message
and suggestion
Violets are red,
Roses are blue,
As August winds whisper,
Take a chance, then rest too.
<hr>
Appreciate it as always @xFrednet
<img width="601" height="744" alt="image"
src="https://github.com/user-attachments/assets/a0e4af41-da97-4565-881b-549ed51d7fc5"
/>
<hr>
Cats for the next release can be traditionally nominated in the comments
:D
Please be more active and cat-minded 😻
changelog: none
r? flip1995
match on `StmtKind` directly
use a let-chain
break up match for a nicer let-chain
shorten `get_line`
move `expr` check down in the inside case as well
for consistency
use `shrink_to_hi`
Apply suggestion
Co-authored-by: Samuel Tardieu <sam@rfc1149.net>
Apparently, one can surround a pattern with an arbitrary number of
parens, and the resulting `Pat` won't include the span of those parens.
And the previous approach extended the to-be-deleted span all the way to
the end of `Pat`'s span, so it included the closing paren.
I think the new approach is more robust anyway, since all we care to
remove (besides the `_`) is the `:`, so we search just for that.
~This does leave one extra whitespace in one of the test cases, but I'd
say let rustfmt handle that.~ fixed in the third commit
changelog: [`let_with_type_underscore`]: don't eat closing paren in `let
(i): _ = 0;`
fixes https://github.com/rust-lang/rust-clippy/issues/15377
Now that `if let` chains have been introduced, the `if_chain` external
crate is no longer necessary. Dropping special support for it also
alleviates the need to keep the crate as a dependency in tests.
This is a cleanup PR.
changelog: none
When an expression is made of a `!` or `-` unary operator which does not
change the type of the expression, use a new variant in `Sugg` to denote
it. This allows replacing an extra application of the same operator by
the removal of the original operator instead.
Some suggestions will now be shown as `x` instead of `!!x`. Right now,
no suggestion seems to produce `--x`.
changelog: none
When an expression is made of a `!` or `-` unary operator which does not
change the type of the expression, use a new variant in `Sugg` to denote
it. This allows replacing an extra application of the same operator by
the removal of the original operator instead.
Also, when adding a unary operator to a suggestion, do not enclose the
operator argument in parentheses if it starts with a unary operator
itself unless it is a binary operation (including `as`), because in this
case parentheses are required to not bind the lhs only.
Some suggestions will now be shown as `x` instead of `!!x`. Right now,
no suggestion seems to produce `--x`.
When a bare CR is present in a four slashes comment, keep triggering the
lint but do not issue a fix suggestion as bare CRs are not supported in
doc comments. An extra note is added to the diagnostic to warn the user
about it.
I have put the test in a separate file to make it clear that the bare CR
is not a formatting error.
Fixesrust-lang/rust-clippy#15174
changelog: [`four_forward_slashes`]: warn about bare CR in comment, and
do not propose invalid autofix
Now that `if let` chains have been introduced, the `if_chain` external
crate is no longer necessary. Dropping special support for it also
alleviates the need to keep the crate as a dependency in tests.
Closesrust-lang/rust-clippy#15348
The span of the `as` expr is also incorrect, but I believe it is not a
bug from Clippy.
changelog: [`cast-lossless`] fix wrong suggestions when casting type is
from macro input
Samuel Tardieu