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.
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
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
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
```
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.
