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.
Lint for holding locks across await points
Fixes#4226
This introduces the lint await_holding_lock. For async functions, we iterate
over all types in generator_interior_types and look for types named MutexGuard,
RwLockReadGuard, or RwLockWriteGuard. If we find one then we emit a lint.
changelog: introduce the await_holding_lock lint
Fixes#4226
This introduces the lint await_holding_lock. For async functions, we iterate
over all types in generator_interior_types and look for types named MutexGuard,
RwLockReadGuard, or RwLockWriteGuard. If we find one then we emit a lint.
Update the changelog update documentation
I just started working on updating the changelog. Hopefully the docs are a bit clearer now?
r? @flip1995
changelog: none
If let else mutex
changelog: Adds lint to catch incorrect use of `Mutex::lock` in `if let` expressions with lock calls in any of the blocks.
closes: #5219
