This makes the last arm significantly shorter, but marginally shortens
the other ones as well
- I first removed the length comparisons from the match guards since
they were already present in `(unordered_)over`, but then brought them
back since they are quite a helpful "guard clause"
- It's a bit unfortunate that the `Slice`/`Array` arm can't use `over`
as well, which creates some asymmetry, but changing the signature of
`over` to accept arbitrary iterators felt like too much to me,
especially because we'd lose the ability to compare the lengths of the
two inputs (which could've been mitigated by `ExactLenIterator::len`,
but that method is still unstable AFAIR)
One other option would be to only use `unordered_over` in the last arm,
and not `over`, but I think `over` is not that bad..
changelog: none
`assign_op_pattern` can be used in a `const` context if the trait
definition as well as the implementation of the corresponding `Assign`
pattern is `const` as well.
The lint was temporarily deactivated in the compiler repository for all
`const` contexts to avoid false positives when operators were
potentially constified. This reenables it when appropriate now that the
repositories have been synced.
Closesrust-lang/rust-clippy#15285
changelog: [`assign_op_pattern`]: trigger in `const` contexts when
appropriate
r? @flip1995
`assign_op_pattern` can be used in a `const` context if the
trait definition as well as the implementation of the corresponding
`Assign` pattern is `const` as well.
Basically continuing the work in
https://github.com/rust-lang/rust-clippy/issues/6680
Honestly I think the lint could also be run on (trait) impl items, but I
didn't implement that because of the feature freeze. If that is deemed
okay to add in this PR though, I could happily do so.
changelog: none
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
create `Option<Region>` in a separate `filter_map`
reduces nesting a bit
replace a bunch of `and_then`s with a clearer(?) let-chain
`too_many_lines` no more!
use free-standing `zip`
add some comments
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
This requires making the `deref_addrof` lint a late lint instead of an
early lint to check for types.
changelog: [`deref_addrof`]: do not suggest implicit `DerefMut` on
`ManuallyDrop` union fields
Fixrust-lang/rust-clippy#14386
fixesrust-lang/rust-clippy#14869
Added a simple check if both chars are of length 3
If they are, we skip the check for that pair.
This won't handle the 4 v 3 case.
Not sure if this was the intent of the issue.
Also saw we have some hardcoded exemptions for `set, get` and `lhs, rhs`
Tried removing them thinking they would be handled by the new condition.
But we have to keep because they allow for `bla_lhs` v `bla_rhs` to be
skipped
changelog:[`similar_names`]: Stop triggering for 3-character names
Revert "Partially outline code inside the panic! macro".
This reverts https://github.com/rust-lang/rust/pull/115670
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
