Closesrust-lang/rust-clippy#8244Closesrust-lang/rust-clippy#15041
This feels like a bug with the compiler, because the panic happens when
`Diag` is getting unwinded. However, `drop()` is already called in
`.cancel()` so this should not happen.
In this PR, I find a workaround to just call `emit()`, since the
`DiagCtxt` here is just a `io::sink`, nothing will happen and the panic
just goes away.
changelog: [`needless_doctest_main`] fix panic when doctest is invalid
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from `libc`.
I don't really trust callgrind when it says I've turn 81 billion instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20 times
without incr" method and it went from 0.31s-0.45s to 0.25s constistently.
(Profiled, and "benchmarked") on tokio.
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`
Replace some `Option<Span>` with `Span` and use DUMMY_SP instead of None
Turns out many locations actually have a span available that we could use, so I used it
Add a new `mismatched-lifetime-syntaxes` lint
The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:
- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:
```rust
// Lint will warn about these
fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
fn(&'static u8) -> &u8;
```
- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:
```rust
// Lint will not warn about these
fn(&u8) -> &'_ u8;
fn(&'_ u8) -> &u8;
fn(&u8) -> ContainsLifetime<'_>;
```
- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.
---
This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
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
Fix false positives on broken link detection
Refactor variable names
Fix doc comment about broken link lint
Refactor, remove not used variable
Improve broken link to catch more cases and span point to whole link
Include reason why a link is considered broken
Drop some checker because rustdoc already warn about them
Refactor to use a single enum instead of multiple bool variables
Fix lint warnings
Rename function to collect broken links
Warn directly instead of collecting all entries first
Iterate directly rather than collecting
Temporary change to confirm with code reviewer the next steps
Handle broken links as part of the fake_broken_link_callback handler
Simplify broken link detection without state machine usage
Fix typos
Add url check to reduce false positives
Drop reason enum as there is only one reason
Fix duplicated diagnostics
Fix linter
