Result<T, E> has an `ok()` method that adapts a Result<T,E> into an Option<T>.
It's possible to get around this adapter by writing Result<T,E>.map_or(None, Some).
This lint is implemented as a new variant of the existing
[`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)
Improve docs for option_option
Hint about using tri-state enums to replace legitimate uses of `Option<Option<_>>`
changelog: The docs for `option_option` now suggest using a tri-state enum
useless Rc<Rc<T>>, Rc<Box<T>>, Rc<&T>, Box<&T>
refers to #2394
changelog: Add lints for Rc<Rc<T>> and Rc<Box<T>> and Rc<&T>, Box<&T>
this is based on top of another change #5310 so probably should go after that one.
Downgrade option_option to pedantic
Based on a search of my work codebase (\>500k lines) for `Option<Option<`, it looks like a bunch of reasonable uses to me. The documented motivation for this lint is:
> an optional optional value is logically the same thing as an optional value but has an unneeded extra level of wrapping
which seems a bit bogus in practice. For example a typical usage would look like:
```rust
let mut host: Option<String> = None;
let mut port: Option<i32> = None;
let mut payload: Option<Option<String>> = None;
for each field {
match field.name {
"host" => host = Some(...),
"port" => port = Some(...),
"payload" => payload = Some(...), // can be null or string
_ => return error,
}
}
let host = host.ok_or(...)?;
let port = port.ok_or(...)?;
let payload = payload.ok_or(...)?;
do_thing(host, port, payload)
```
This lint seems to fit right in with the pedantic group; I don't think linting on occurrences of `Option<Option<T>>` by default is justified.
---
changelog: Remove option_option from default set of enabled lints
Stop updating the lint counter with every new lint
r? @Manishearth
This PR does two things:
1. Clean up the clippy_dev module a bit (first 3 commits; cc #5394 )
2. Make the counter in the README count in steps of 50 lints. Also use a `lazy_static` `Vec` for the lint list, so no counter is required there anymore.
changelog: none
Lint unnamed address comparisons
Functions and vtables have an insignificant address. Attempts to compare such addresses will lead to very surprising behaviour. For example: addresses of different functions could compare equal; two trait object pointers representing the same object and the same type could be unequal.
Lint against unnamed address comparisons to avoid issues like those in rust-lang/rust#69757 and rust-lang/rust#54685.
changelog: New lints: [`fn_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294), [`vtable_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294)
Document how to create releases and backports
This PR adds documentation on how to create Clippy releases and backports.
This PR also introduces a new backport/release process for Clippy:
- A beta branch is introduced: https://github.com/rust-lang/rust-clippy/tree/beta
- Backports are now done by PRs to the `beta` branch
- also commits to the beta branch will be deployed, so that the documentation page has a tab for the Clippy beta release.
This has two advantages:
1. The Clippy release process is closer to the Rust release process: stable releases are tagged, the beta release has its own branch
2. Backports to beta are easier, since they don't need as much coordination as before. No new branch has to be created for a backport. Just a PR to the beta branch, like in the Rust repo.¹
I tested the deployment here: https://github.com/flip1995/rust-clippy/runs/534465081 and it created this commit: 734503377e, so it works.
r? @Manishearth your thoughts?
[Rendered (release.md)](https://github.com/flip1995/rust-clippy/blob/doc_release_backport/doc/release.md)
[Rendered (backport.md)](https://github.com/flip1995/rust-clippy/blob/doc_release_backport/doc/backport.md)
changelog: none
---
¹: For this, we may have to modify the CI, so that beta rustc is used to check PRs to beta (or we test it locally, and merge it without bors)
`unused_self` false positive
fixes#5351
Remove the for loop in `unused_self` so that lint enabled for one method doesn't trigger on another method.
changelog: Fix false positive in `unused_self` around lint gates on impl items
git attribute macros not allowed in submodules
This change simply moves the `rust` macro definition directly into the
attributes for `*.rs` files.
git commands that recurse from the rust toplevel tree into submodules
produce errors in clippy due to the fact that:
"Custom macro attributes can be defined only in top-level
gitattributes files"
For example, from the toplevel `rust` directory in a rustc development
build, try:
$ git grep "search string" --recurse-submodules
Embedded within the actual results is the error message:
[attr]rust text eol=lf whitespace=tab-in-indent,trailing-space,tabwidth=4
not allowed: src/tools/clippy/.gitattributes:1
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `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.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `cargo dev update_lints`
- [ ] Added lint documentation
- [ ] 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.
---
changelog: none
