Fix suggestions that need parens in `from_iter_instead_of_collect` lint
Fixes broken suggestions that need parens (i.e.: range)
Fixes: #6648
changelog: none
Stabilize workspace wrapper.
This fixes it so that `cargo clippy` doesn't share the same cache artifacts as `cargo check`. The Cargo side was stabilized a while ago (https://github.com/rust-lang/cargo/pull/8976), so this should be ready to go. I'm not aware of any blockers or concerns.
Closes#4612
---
changelog: `cargo clippy` no longer shares the same build cache as `cargo check`.
This renames the variants in HIR UnOp from
enum UnOp {
UnDeref,
UnNot,
UnNeg,
}
to
enum UnOp {
Deref,
Not,
Neg,
}
Motivations:
- This is more consistent with the rest of the code base where most enum
variants don't have a prefix.
- These variants are never used without the `UnOp` prefix so the extra
`Un` prefix doesn't help with readability. E.g. we don't have any
`UnDeref`s in the code, we only have `UnOp::UnDeref`.
- MIR `UnOp` type variants don't have a prefix so this is more
consistent with MIR types.
- "un" prefix reads like "inverse" or "reverse", so as a beginner in
rustc code base when I see "UnDeref" what comes to my mind is
something like "&*" instead of just "*".
Downgrade trivial_regex to nursery
See #6690. I think there is still value in a trivial_regex lint, but only if clippy can tell that the regex is only ever constructed and applied to a single input.
```rust
let regex = Regex::new("trivial_regex")?;
println!("{}", regex.is_match(s));
// `regex` never used again
```
---
changelog: remove `trivial_regex` from default set of enabled lints
lintcheck: support git sources
This adds support for git sources in `cargo dev-lintcheck`
You can add a git source to `clippy_dev/lintcheck_crates.toml` by having a `git_url` and a `git_hash` key instead of the `versions` array.
The repo will the be cloned and checked out to the requested commit before checking it with clippy.
Fixes https://github.com/rust-lang/rust-clippy/issues/6642
changelog: lintcheck: support git sources
disallowed_methods: Support functions in addition to methods
## Context:
Hey all! I have a particular use case where I'd like to ban certain functions in a code base I work on. For example, I want to ban `Instant::now()` (among others) as we have a time service for mocking time in deterministic simulation tests. Obviously, it doesn't make sense to include a lint like this for all clippy users. Imagine my excitement when I spotted the new `disallowed_methods` lint in clippy--perfect! Unfortunately, after playing around with it for a bit, I was frustrated to realize that it didn't support functions like `Instant::now()`, so I've added support for them in this PR.
It might also make sense to rename the lint from `disallowed_methods` -> `disallowed_functions`, though I've held off from including that rename in this change, since I'm unsure of clippy's breaking change policy.
## Change
Support functions in addition to methods. In other words, support:
`disallowed_methods = ["alloc::vec::Vec::new"]` (a function) in addition to
`disallowed_methods = ["alloc::vec::Vec::leak"]` (a method).
Improve the documentation to clarify that users must specify the full qualified path for each disallowed function, which can be confusing for reexports. Include an example `clippy.toml`.
Simplify the actual lint pass so we can reuse `utils::fn_def_id`.
changelog: disallowed_method: Now supports functions in addition to methods
Add new lint `filter_map_identity`
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[x] Followed [lint naming conventions][lint_naming]
- \[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`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR.
-->
This commit adds a new lint named filter_map_identity.
This lint is the same as `flat_map_identity` except that it checks for the usage of `filter_map`.
---
Closes#6643
changelog: Added a new lint: `filter_map_identity`
Adds a new lint that checks if there is a semicolon on the last block statement if it returns nothing
changelog: Added a new lint: `SEMICOLON_IF_NOTHING_RETURNED`
fixes#6467
Adds the `SEMICOLON_IF_NOTHING_RETURNED` lint and therefore closes#6467.
Cleanup path-to-local checks
changelog: none
It seemed like too much ceremony going on to check if an expression matches a variable. So I created two util functions `path_to_local(Expr) -> Option<HirId>` and `path_to_local_id(Expr, HirId) -> bool` to make this easier, and used them wherever applicable.
I changed logic in a few places to use `HirId` instead of `Symbol` where it was easy to do so. I believe this is more correct and may even fix some bugs.
I also removed some calls to `qpath_res`. This is not needed if you are only looking for a `Res::Local`.
As a note, I wanted to name the util functions in a way that encourages understanding of the HIR.
