Based on
https://github.com/rust-lang/rust-clippy/pull/15520#discussion_r2372599748,
with the following changes/additions:
- No longer use the `Trait` enum for quickly filtering out irrelevant
impls -- instead, check the `trait_of` basically right away:
1. pre-fetch `DefId`s of the relevant traits into the lint pass
2. reuse `cx.tcx.impl_trait_ref`'s output for the the `DefId` of the
trait being implemented
3. compare those `DefId`s, which should be very cheap
- Next, check whether `self_ty` implements the other relevant trait.
- Pre-filter impl items in the same (lazy) iterator, but delay the
proc-macro check as much as possible
changelog: none
Not auto-assigning since @blyxyas and/or @Jarcho will be the ones
reviewing it:
r? ghost
Resolvesrust-lang/rust-clippy#15780.
I didn't get any feedback on that issue. So I hope it is okay that I
charged ahead and addressed it.
changelog: Allow `explicit_write` in tests
The way clippy checked for SAFETY comments above attributes was wrong:
- It wasn't considered for items
- It cause an ICE with some attributes
- When considering comments above attributes, it didn't considered
comments below them, causing some unlintable situations.
This PR tries to fix this by delegating the skipping of attributes to
the function analyzing the source code itself.
changelog: [`unnecessary_safety_comment`]: Taking into account comments
above attributes for items
Fixesrust-lang/rust-clippy#14555Fixesrust-lang/rust-clippy#15684Fixesrust-lang/rust-clippy#15754
improve coverage
Considering comments above attributes for items
Fixed the ICE and safety comments between attributes
- No longer using attr.span()
- ignoring attributes manually
Improve error messages on unsafe fns
This lint aims at detecting unusual names used in Clippy source code,
such as `appl` or `application` for a `rustc_errors::Applicability`
variable, instead of `app` and `applicability` which are commonly used
throughout Clippy.
This helps maintaining the consistency of the Clippy source code.
It is currently implemented for:
- `Applicability`: `app` or `applicability`
- `EarlyContext`/`LateContext`: `cx`
- `TyCtxt`: `tcx`
changelog: none
Add a config option `inherent-impl-lint-scope` to the lint
`multiple_inherent_impl` to target a different scope according to
people's needs. It can take three values: `module`, `file`, and `crate`
(default).
- `module` is the weakest option. It lints if there are two or more
impls in the same module.
- `file` is a bit stronger, since it lints if there are two or more
impls in the same file. So, this triggers the lint (where it did not
with module):
- `crate` is the strongest of them; it triggers as soon as there are two
or more impls anywhere in the crate. It is the current behaviour of the
lint, so it's the default option.
changelog: [`multiple_inherent_impl`] : Add config option (`module`,
`file` or `crate`) to target specific scope
fixesrust-lang/rust-clippy#14867
This lint aims at detecting unusual names used in Clippy source code,
such as `appl` or `application` for a `rustc_errors::Applicability`
variable, instead of `app` and `applicability` which are commonly used
throughout Clippy.
This helps maintaining the consistency of the Clippy source code.
The missing external macro test for `non_canonical_clone_impl` was
caught thanks to lintcheck -- I went ahead and added all the other
combinations of the test while at it
This introduces a new way of identifying items/paths using extension
traits with a composable set of functions rather than unique functions
for various combinations of starting points and target items. Altogether
this is a set of five traits:
* `MaybeTypeckRes`: Allows both `LateContext` and `TypeckResults` to be
used for type-dependent lookup. The implementation here will avoid ICEs
by returning `None` when debug assertions are disabled. With assertions
this will assert that we don't silently lookup anything from a different
body than the current one and that a definition actually exists.
* `HasHirId`: Simply a convenience to allow not typing `.hir_id` at call
sites.
* `MaybeQPath`: This is the old `MaybePath`. Extension functions for
type-dependent path lookups exist here. A lot of these functions aren't
used in the current PR, but what they accomplish is done in various
places I haven't cleaned up yet.
* `MaybeResPath`: Like `MaybeQPath`, but only does non-type-dependent
lookup (`QPath::Resolved`).
* `MaybeDef`: Extension functions for identifying the current definition
and accessing properties. Implemented for several types for convenience.
`MaybeDef` is implemented for `Option` to allow chaining methods
together. e.g.
`cx.ty_based_def(e).opt_parent(cx).opt_impl_ty(cx).is_diag_item(..)`
would chaining `and_then` or `if let` on every step. `MaybeQPath` and
`MaybeResPath` are also implemented for `Option` for the same reason.
`ty_based_def` is just a shorter name for `type_dependent_def`. I'm not
really attached to it, but it's nice that it's a little shorter.
changelog: none
