- 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
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
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
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
- The main message should point out what's wrong, not directly suggest a
solution.
- The second part of the message is a separate advice, so it should be
emitted separately.
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
changelog: [`expl_impl_clone_on_copy`]: honor `allow`/`expect`
attributes on both the type declaration and the `impl`
Fixesrust-lang/rust-clippy#15842
r? @blyxyas
changelog: [`unnecessary_option_map_or_else`]: Added lint
unnecessary_option_map_or_else. As suggested in the issue description,
the implementation takes as reference the issue
rust-lang/rust-clippy#7328. The tests for lints `option_if_let_else` and
`or_fun_call` needed to be adjusted to comply with new lint.
fixesrust-lang/rust-clippy#14588
Fixesrust-lang/rust-clippy#15805
ICE bisects to 9457d640b7, which handles the span incorrectly when part
of the path originates from internal declarative macro.
changelog: none
test: Subtract code_offset from width for ui_testing
`annotate-snippets` does not have a "UI test" mode like `rustc`, [where the code offset is not subtracted from the column width](f34ba774c7/compiler/rustc_errors/src/emitter.rs (L1985-L1987)). This makes it so `annotate-snippets` will shift the output for some very long tests 5 - 7 columns to the left. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I figured it would be best if `rustc` started subtracting the code offset from the width as well.
The first commit exists to keep the test output changes of adding a new line to a test separate from adding the `--diagnostic-width` flag in the second commit. This makes it easier to verify that adding the flag does not affect the test's output.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Volatile reads and writes to non-primitive types are not well-defined,
and can cause problems.
Fixesrust-lang/rust-clippy#15529
changelog: [`volatile_composites`]: Lint when read/write_volatile is
used on composite types
(structs, arrays, etc) as their semantics are not well defined.
now lints on
```rs
let mut x = [1,2,3].into_iter();
loop {
let Some(x) = x.next() else { break };
dbg!(x);
}
```
```
changelog: [`while_let_loop`]: extend to lint on `let else`
```
