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)
