It's nice to come up with a clever algorithm
(https://github.com/rust-lang/rust-clippy/pull/15667), but it's even
nicer to reuse logic that already exists elsewhere.
changelog: none
r? @samueltardieu as you reviewed the original PR
`NB!` is extremely alien + not used anywhere else in repo (per github
search).
`Notes => Note`. At first thought was convention (written from
perspective of the lint), but not seen anywhere else in repo (per github
search).
Implication: clearer docs
Changes made from github web editor; no tests/checks performed.
changelog: none
- Make the diagnostic message actually desribe the problem
- Always give the suggestion, by using `snippet_with_context`
- Make the suggestion verbose, because we sometimes lint multiline exprs
like `match`es
changelog: [`manual_option_as_slice`]: improve diagnostics
- Make the diagnostic message actually desribe the problem
- Make the suggestion verbose, because we lint multiline exprs
changelog: [`match_as_ref`]: improve diagnostics
- only lint on definitions of offending mutexes, not all their uses
(fixes https://github.com/rust-lang/rust-clippy/issues/13378)
- give more orderly help messages
- stop linting on `Mutex<*const T>` (see the corresponding commit for
context)
- offer (partial) suggestions
The last change might be deemed a bit too much for the feature freeze,
but it can be easily extracted out into a separate PR.
changelog: [`mutex_atomic`]: only lint the definitions, not uses
changelog: [`mutex_atomic`]: better help messages, and suggestions
changelog: [`mutex_atomic`]: don't lint `Mutex<*const T>`
changelog: [`mutex_integer`]: only lint the definitions, not uses
changelog: [`mutex_integer`]: better help messages, and suggestions
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
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
`Mutex<*const _>` doesn't make a lot of sense (there can be no
contention over a read-only reference), but `AtomicPtr::new(*const _)`
straight up doesn't compile
