New lint `match_vec_item`
Added new lint to warn a match on index item which can panic. It's always better to use `get(..)` instead.
Closes#5500
changelog: New lint `match_on_vec_items`
Implement mismatched_target_os lint
I've extended the check suggested in the issue to all the currently supported operating systems instead of limiting it to `linux` and `macos`, let me know if we want to do this.
Also, I've restored the text `There are over XXX lints ...` in the README as it was matched against by `cargo dev new_lint`.
changelog: Added `mismatched_target_os` lint to warn when an operating system is used in target family position in a #[cfg] attribute
Closes#3949
- Show just one error message with multiple suggestions in case of
using multiple times an OS in target family position
- Only suggest #[cfg(unix)] when the OS is in the Unix family
- Test all the operating systems
Don't trigger while_let_on_iterator when the iterator is recreated every iteration
r? @phansch
Fixes#1654
changelog: Fix false positive in [`while_let_on_iterator`]
Rollup of 5 pull requests
Successful merges:
- #5408 (Downgrade match_bool to pedantic)
- #5505 (Avoid running cargo+internal lints when not enabled)
- #5516 (Add a note to the beta sections of release.md)
- #5517 (Deploy time travel)
- #5523 (Add lifetime test case for `new_ret_no_self`)
Failed merges:
r? @ghost
changelog: rollup
Deploy time travel
Since not only commits to the master branch, but also tags and the beta branch are deployed, we have to be cautious which version of the deploy script is used. GHA always runs the workflow that is commited on the `ref`, that gets tested. For tagged commits. this is 6 weeks outdated workflows/scripts. To prevent this, this workflow first checks out the deploy.sh script, the website templates and all python scripts generating files for the website.
changelog: none
Downgrade match_bool to pedantic
I don't quite buy the justification in https://rust-lang.github.io/rust-clippy/. The justification is:
> It makes the code less readable.
In the Rust codebases I've worked in, I have found people were comfortable using `match bool` (selectively) to make code more readable. For example, initializing struct fields is a place where the indentation of `match` can work better than the indentation of `if`:
```rust
let _ = Struct {
v: {
...
},
w: match doing_w {
true => ...,
false => ...,
},
x: Nested {
c: ...,
b: ...,
a: ...,
},
y: if doing_y {
...
} else { // :(
...
},
z: ...,
};
```
Or sometimes people prefer something a bit less pithy than `if` when the meaning of the bool doesn't read off clearly from the condition:
```rust
if set.insert(...) {
... // ???
} else {
...
}
match set.insert(...) {
// set.insert returns false if already present
false => ...,
true => ...,
}
```
Or `match` can be a better fit when the bool is playing the role more of a value than a branch condition:
```rust
impl ErrorCodes {
pub fn from(b: bool) -> Self {
match b {
true => ErrorCodes::Yes,
false => ErrorCodes::No,
}
}
}
```
And then there's plain old it's-1-line-shorter, which means we get 25% more content on a screen when stacking a sequence of conditions:
```rust
let old_noun = match old_binding.is_import() {
true => "import",
false => "definition",
};
let new_participle = match new_binding.is_import() {
true => "imported",
false => "defined",
};
```
Bottom line is I think this lint fits the bill better as a pedantic lint; I don't think linting on this by default is justified.
changelog: Remove match_bool from default set of enabled lints
It looks like after changing to "there are more than 120 lints", an older PR was merged
and resolving merge conflicts this was changed back to "there are 123 lints" causing the update-script to silently fail.
Changed back the README.md back to the new format fixes the problem.
