The rationale is the same as discussed in 0b0f96e:
> It can be rather surprising when new lints pop up when a new stable
> toolchain is released. Let's pin this check to a specific version to
> avoid those surprises.
In deciding which version of clippy to use, I went with the MSRV since
that's what's been done historically. The other option was to read
from the repo a version number specifically for clippy, but I was
afraid that adding one more version number to juggle would increase
the odds that it would be forgotten and fall out of sync.
Note that this approach uses rustup to install the toolchain
dynamically rather than making use of an action. The advantage of this
method is that it allows a single pull request to contain the version
bump and suggested code changes (this is due to the fact that
actions-rs/clippy-check requires a GitHub API token with write
permission, but a token of this type is only available when triggering
on `pull_request_target` which runs the action using the configuration
from the base of the pull request rather than the merge commit). The
disadvantage of this approach is that the toolchain setup can no
longer be cached by the underlying layering mechanism used by GitHub
actions (unlikely to significantly affect this project).
actions-rs/clippy-check only requires read/write access to the
"checks" scope. When the "permissions" object is present, all of the
scopes default to "none".
bors already tests the *result* of merging PRs into master, and then
pushes the *exact same commit* to master on success, so it's guaranteed
to pass CI. No point in running everything again.
This'll make other CI runs faster, since we have so many jobs that we're
always running against the GHA limit of 10 concurrent jobs.
On `std` targets, `OsRng` is used by default. The user can supply a custom impl
by enabling the `rand-custom-impl` Cargo feature and using the `rand_custom_impl!()` macro.
Specifying a custom impl is mandatory when `std` is not enabled.
It can be rather surprising when new lints pop up when a new stable
toolchain is released. Let's pin this check to a specific version to
avoid those surprises.
Might as well run the lints on our tests and examples. When I first
started doing this cleanup, I thought this was the default, but I must
have run `cargo clippy --all-targets` at some point in there.
