new lint: `single_char_lifetime_names`
This pull request adds a lint against single character lifetime names, as they might not divulge enough information about the purpose of the lifetime. This can make code harder to understand. I placed this in `restriction` rather than `pedantic` (as suggested in #8233) since most of the Rust ecosystem already uses single character lifetime names (to my knowledge, at least) and since single character lifetime names aren't incorrect. I'd be happy to change this upon request, however. Fixes#8233.
- [x] Followed lint naming conventions
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `cargo dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo dev fmt`
changelog: new lint: [`single_char_lifetime_names`]
This pull request adds a lint against single character lifetime names, as they might not divulge enough information about the purpose of the lifetime. This can make code harder to understand. I placed this in `restriction` rather than `pedantic` (as suggested in #8233) since most of the Rust ecosystem already uses single character lifetime names (to my knowledge, at least) and since single character lifetime names aren't incorrect. I'd be happy to change this upon request, however. Fixes#8233.
- [x] Followed lint naming conventions
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `cargo dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo dev fmt`
changelog: new lint: [`single_char_lifetime_names`]
Set binary-dep-depinfo in .cargo/config.toml
Fixes#8248
According to https://doc.rust-lang.org/cargo/reference/unstable this
seems to be the right place to set it, and it does fix the build for me.
I haven't removed the other `rustflags` because perhaps it's needed on
different cargo/rust versions?
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
Fixes#8248
According to https://doc.rust-lang.org/cargo/reference/unstable this
seems to be the right place to set it, and it does fix the build for me.
I haven't removed the other `rustflags` because perhaps it's needed on
different cargo/rust versions?
Change `unnecessary_to_owned` `into_iter` suggestions to `MaybeIncorrect`
I am having a hard time finding a good solution for #8148, so I am wondering if is enough to just change the suggestion's applicability to `MaybeIncorrect`?
I apologize, as I realize this is a bit of a cop out.
changelog: none
Region info is completely unnecessary for upvar capture kind computation
and is only needed to create the final upvar tuple ty. Doing so makes
creation of UpvarCapture very cheap and expose further cleanup opportunity.
Allow running lintcheck with a renamed rust-clippy dir
I have Clippy checked out in `rust/clippy` rather than `rust/rust-clippy`, this allows lintcheck to still run in that case
changelog: none
Better detect when a field can be moved from in `while_let_on_iterator`
fixes#8113
changelog: Better detect when a field can be moved from in `while_let_on_iterator`
Fix `type_repetition_in_bounds`
fixes#7360fixes#8162fixes#8056
changelog: Check for full equality in `type_repetition_in_bounds` rather than just equal hashes
Remove in_macro from clippy_utils
changelog: none
Previously done in #7897 but reverted in #8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO.
r? `@llogiq`
New macro utils
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
Fix `clippy::use-self`` warning in ` src/main.rs`
`ClippyCmd` warnings gets generated due to addition of `clippy::use-self`. This PR fixes that.
```
warning: unnecessary structure name repetition
--> src/main.rs:99:9
|
99 | ClippyCmd {
| ^^^^^^^^^ help: use the applicable keyword: `Self`
|
= note: `-W clippy::use-self` implied by `-W clippy::nursery`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#use_self
```
---
changelog: none
Remove `NullOp::Box`
Follow up of #89030 and MCP rust-lang/compiler-team#460.
~1 month later nothing seems to be broken, apart from a small regression that #89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely.
r? `@jonas-schievink`
`@rustbot` label T-compiler
[`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`
fixes#7210
changelog: [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`
wrong_self_convention: Match `SelfKind::No` more restrictively
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see #8142).
With this patch, the code above now gives a lint as expected.
fixes#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
return_self_not_must_use document `#[must_use]` on the type
Inspired by a discussion in rust-lang/rust-clippy#8197
---
r? `@llogiq`
changelog: none
The lint is this on nightly, therefore no changelog entry for you xD
Inspired by a discussion in rust-lang/rust-clippy#8197
---
r? `@llogiq`
changelog: none
The lint is this on nightly, therefore no changelog entry for you xD
