| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r? @ghost
changelog: none
|
|
|
|
|
|
|
|
fixes #13934
I modified the part for checking if the map is used so that it can check
field and index exprs.
changelog: [`map_entry`]: fix FP on struct member
|
|
In the case where `iter` is a `DoubleEndedIterator`, replacing a call to
`iter.last()` (which consumes `iter`) by `iter.next_back()` (which
requires a mutable reference to `iter`) cannot be done when `iter` is a
non-mutable binding which is not a mutable reference. When possible, a
local immutable binding is made into a mutable one.
Also, the applicability is switched to `MaybeIncorrect` and a note is
added to the output when the element types have a significant drop,
because the drop order will potentially be modified because
`.next_back()` does not consume the iterator nor the elements before the
last one.
Fix #14139
changelog: [`double_ended_iterator_last`]: do not trigger on
non-reference immutable receiver, and warn about possible drop order
change
|
|
`iter.last()` will drop all elements of `iter` in order, while
`iter.next_back()` will drop the non-last elements of `iter` when
`iter` goes out of scope since `.next_back()` does not consume its
argument.
When the transformation proposed by `double_ended_iterator_last` would
concern an iterator whose element type has a significant drop, a note is
added to warn about the possible drop order change, and the suggestion
is switched from `MachineApplicable` to `MaybeIncorrect`.
|
|
|
|
In the case where `iter` is a `DoubleEndedIterator`, replacing a call to
`iter.last()` (which consumes `iter`) by `iter.next_back()` (which
requires a mutable reference to `iter`) cannot be done when `iter`
Is not a mutable binding or a mutable reference.
When `iter` is a local binding, it can be made mutable by fixing its
definition site.
|
|
fixes #14148
Another case of #13077 and #8646
changelog: [`needless_option_as_deref`]: fix FP in trait
|
|
If the part being replaced is an `if` expression following an `else`,
the replacement expression must be blockified.
|
|
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
|
|
Cleans up some changes from
https://github.com/rust-lang/rust-clippy/pull/11421
I searched for any `.stderr` files where the number of errors changed
and reverted + manually added the annotations for them
Also fixes `tests/ui/asm_syntax_not_x86.rs`
r? @flip1995
changelog: none
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a solution for `tests/ui-internal/custom_ice_message.rs`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adding annotations, it doesn't work anymore
|
|
|
|
|
|
Fixed #14156
changelog: none
|
|
implement `Copy` (#14207)
Fix #14201
changelog: [`unnecessary_map_or`]: do not consume the comparison value
if it does not implement `Copy`
|
|
This is the lint described at
https://github.com/rust-lang/rust/pull/136308#issuecomment-2625485331
that recommends using HTML to nest links inside code.
changelog: [`doc_link_code`]: warn when a link with code and a code span
are back-to-back
|
|
|
|
(#13953)
Fixes #13885.
Fixes https://github.com/rust-lang/rust-clippy/issues/14007.
Problem was that I forgot to check whether or not the `span` was a
"real" one. Because if not, then it starts pointing to pretty much only
wrong content, hence the problems we saw with clippy linting on
`clippy.toml`.
changelog: Fix `literal_string_with_formatting_args` lint emitted when
it should not
r? @samueltardieu
|
|
|
|
Fixes the exposed release channel
Bump version to 0.4.1
|
|
|
|
`mem::replace(opt, Some(v))` can be replaced by `opt.replace(v)`.
Close #14195
changelog: [`mem_replace_option_with_some`]: new lint
|
|
`mem::replace(opt, Some(v))` can be replaced by `opt.replace(v)`.
|
|
|
|
Checks for `Read::bytes()` on an unbuffered Read type.
The default implementation calls `read` for each byte, which can be very
inefficient for data that’s not in memory, such as `File`.
Considerations which I'd like to have feedback on:
* Currently this lint triggers when `.bytes()` is called on any type
that implements `std::io::Read` but not `std::io::BufRead`. This is
quite aggressive and in and may result in false positives. Alternatives:
* Only trigger on concrete types, not generic types. This does mean that
cases where a function is generic over a `R: Read` and calls `.bytes()`
are not caught by the lint, which could be quite a nasty case of this
bug.
* Only trigger on an allowlist of stdlib types
* Compromise: Is it possible to make this lint `pedantic` on types that
are not on a allowlist?
* Theoretically, a trait implementation of `Read` could override
`.bytes()` with an efficient implementation. I'm not sure how to add
this check to the lint, and I can't find any cases of this being done in
practice.
* I don't think an automatic fix for this lint is possible, but I'd love
to be proven wrong
* This is my first time contributing to clippy, please let me know if I
did anything wrong
Fixes #14087
```
changelog: [`unbuffered_bytes`]: new lint
```
|
|
fix #14192
changelog: [`manual_slice_fill`]: resolve FP caused by missing index
checks for the slice
|
|
|
|
By default, do not lint `.unwrap()` and `.expect(…)` in always const
contexts, as a failure would be detected at compile time anyway.
New options `allow_expect_in_consts` and `allow_unwrap_in_consts`,
defaulting to `true`, can be turned unset to still lint in always const
contexts.
|
|
(#14168)
Fixes #12302
changelog: [`just_underscores_and_digits`]: fix false positive in error
recovery scenario
|
|
Empty idents come from error recovery, and should imply that a
better error has already been emitted.
|
