Closesrust-lang/rust-clippy#14692
The suggestion of `manual_flatten` does not includes the replacement of
`if let` so far despite of `.flatten()` suggestion.
This PR eliminates a redundant `if let`.
changelog: [`manual_flatten`] the suggestion removes `if let`
It doesn't seem to be load bearing for any clippy lints and the rustc
ones that no longer appear behave the same as they would for a `cargo
check`
r? @blyxyas
changelog: none
The suggestion of `manual_flatten` does not includes the replacement
of `if let` so far despite of `.flatten()` suggestion. This change
eliminates a redundant `if let`.
changelog: [`manual_flatten`] the suggestion removes `if let`
Given a type alias as follows, clippy would detect a false positive for
`unused_unit`.
```rust
type UnusedParensButNoUnit = Box<dyn (Fn())>;
```
changelog: [`unused_unit`]: fix false positive for `Fn` bounds
`clippy_utils::ty::InteriorMut::interior_mut_ty_chain` must stop
recursing forever when types are chained indefinitely due to the use of
associated types in generics. A false negative is acceptable, and
documented here.
Should this situation be later identified specifically, a conversion of
`Option` to `Result` would allow separating the infinitely recursive
case from a negative one.
changelog: [`mutable_key_type`]: fix ICE when infinitely associated
generic types are used
Fixesrust-lang/rust-clippy#14935
This PR introduces a lint which detects when `&Box<dyn Any>` is coerced
to `&dyn Any`, which is usually a mistake where the intent was to
directly pass the `dyn Any` inside the box without coercion.
cc @llogiq
Remaining work:
- [x] Documentation
- [x] Generalize from Box to any implementer of `Deref<Target=dyn Any>`
----
changelog: add [`coerce_container_to_any`] lint
Fixesrust-lang/rust-clippy#14958
`disallowed_names` was used to lint code generated by macros. This
behavior can confuse programmers who did not write the macro themselves.
This change suppresses lints for code originating from macros, including
external ones.
changelog: [`disallowed_names`] do not lint macro generated codes
Fixes https://github.com/rust-lang/rust-clippy/issues/11126
It avoids the ICE when the number of lints changes, this is only a
problem for clippy in development but cleaning the clippy dir requires a
lot of rebuilding
changelog: none
changelog: [`doc_suspicious_footnotes`]: lint for text that looks like a
footnote reference but has no definition
This is an alternative to https://github.com/rust-lang/rust/pull/137803,
meant to address the concerns about false positives.
This lint only fires when the apparent footnote reference has a name
that's made from pure ASCII digits. This choice is justified by running
lintcheck on the top 200 crates, plus the clippy default set:
1. [I ran
lintcheck](https://gist.github.com/notriddle/59072476c9c1fd569fee421270dad665)
with a modded version of this lint that didn't check for digits only. It
produced a false positive warning on a line in mdbook that had a regex,
and no true positives at all.
2. [I also ran
lintcheck](https://gist.github.com/notriddle/74eb8c9e1939b9f5c5549bf1d4fa238a)
with a custom lint that fired on any valid footnote reference with a
non-ascii-digit name. `cargo` uses one in its job_queue module, and
that's all it found.
cc @GuillaumeGomez
Closesrust-lang/rust-clippy#14952
The lint suggests using `.display()` on `Path`, which is actually
correct.
changelog: [`unnecessary_debug_formatting`] fix FP inside `Debug` impl
`disallowed_names` was used to lint code generated by macros.
This behavior can confuse programmers who did not write the macro
themselves. This change suppresses lints for code originating from
macros, including external ones.
changelog: [`disallowed_names`] do not lint macro generated codes
Fixes: rust-lang/rust-clippy#14930
changelog: Fix [`print_literal`] and [`write_literal`]'s
suggestion-causes-error when using format argument like `{0:2$.1$}`
`clippy_utils::ty::InteriorMut::interior_mut_ty_chain` must stop
recursing forever when types are chained indefinitely due to the use of
associated types in generics. A false negative is acceptable, and
documented here.
Should this situation be later identified specifically, a conversion of
`Option` to `Result` would allow separating the infinitely recursive
case from a negative one.
When determining when a function or method can be called from a `const`
context, the determination must be made on the instance, not on the
declaration. This makes a difference, for example, with `const_trait`
traits whose implementations may or may not be `const`.
changelog: [`missing_const_for_fn`]: when checking if a function or
method can be called from a `const` context, look at the concrete
implementation rather than at the trait definition
Fixesrust-lang/rust-clippy#14658
r? @Jarcho
If an early return is found under the HIR local declaration node but
before the child process is created, it should not trigger the lint
because the child process has not yet been created.
changelog: [`zombie_process`]: do not complain about early early returns
Fixesrust-lang/rust-clippy#14911
This test checks that all symbols defined in Clippy's `sym.rs` file are
used in Clippy. Otherwise, it will fail with a list of symbols which are
unused.
This test only runs when the `internal` feature is set, to allow
developers to temporarily define new, yet unused symbols without failing
the tests. Also, it will not run as part of the compiler test suite, as
an extra symbol should never be seen as a fatal problem in the compiler
repo.
changelog: none
Looks for `TryFrom` implementations with uninhabited error types and
suggests to implement `From` instead.
Fixesrust-lang/rust-clippy#2144
---
changelog: Add [`infallible_try_from`] lint
I read a blog post about kernel security, and how various features might
get lost while porting to Rust. In kernel C, they have some guardrails
against divulging pointers. An easy way to replicate that in Rust is a
lint for pointer formatting. So that's what this lint does.
---
changelog: new [`pointer_format`] lint
When determining when a function or method can be called from a `const`
context, the determination must be made on the instance, not on the
declaration. This makes a difference, for example, with `const_trait`
traits whose implementations may or may not be `const`.
If an early return is found under the HIR local declaration node but
before the child process is created, it should not trigger the lint
because the child process has not yet been created.
Placeholders are still given for the content of the whole block.
However, if the result of the original `if let` or `match` expression
was assigned, the assignment is reflected in the suggestion.
No-op assignments (`let x = x;`) are skipped though, unless they contain
an explicit type which might help the compiler (`let x: u32 = x;` is
kept).
Closesrust-lang/rust-clippy#362
changelog: [`while_let_loop`]: include `let` assignment in suggestion
`if` expressions don't necessarily contain a block in the `else` part in
the presence of an `else if`. The `else` part, if present, must be
handled as a regular expression, not necessarily as a block expression.
Found while applying Clippy to triagebot and looking at the result. This
also found an issue in Clippy itself.
changelog: [`needless_return`]: look inside `else if` parts as well
