In the current GitHub Actions CI/CD setup, the `deploy` job is not
triggered when a PR is enqueued in the merge queue but only when it is
merged. Since concurrency is not configured for this job, deployments
may fail for later PRs if multiple PRs are merged in quick succession.
(e.g. the deployment for [this
commit](c418714518)
was successful, but the deployment for [this
commit](0a141ab7b8)
that was pushed to `main` immediately afterward failed. (edit: the
latter deployment seems to be rerun))
changelog: none
r? flip1995
In #14116 we added a benchmarking option for Lintcheck, this commit adds
a new chapter to the book AND improves that option into a more usable
state.
It's recommended to review one commit at a time.
- **Document how to benchmark with lintcheck --perf**
- **Several improvements on lintcheck perf (desc.)**
- Now lintcheck perf deletes target directory after benchmarking,
benchmarking with a cache isn't very useful or telling of any
precise outcome.
- Support for benchmarking several times without having to do
a cargo clean.
- Compress perf.data
changelog: none
Introducing a new chapter to the book, known as "Benchmarking Clippy".
It explains the benchmarking capabilities of lintcheck --perf
and gives a concrete example on how benchmark and compare a PR with
master
`rustc_middle` is a huge crate and it's always good to move stuff out of
it. There are lots of similar methods already on `Span`, so these two
functions, `in_external_macro` and `is_from_async_await`, fit right in.
The diff is big because `in_external_macro` is used a lot by clippy
lints.
* Construct lint passes by taking `Conf` by reference.
* Use `HashSet` configs in less places
* Move some `check_crate` code into the pass constructor when possible.
The `restriction` group contains many lints which are not about
necessarily “bad” things, but style choices — perhaps even style choices
which contradict conventional Rust style — or are otherwise very
situational. This results in silly wording like “Why is this bad?
It isn't, but ...”, which I’ve seen confuse a newcomer at least once.
To improve this situation, this commit replaces the “Why is this bad?”
section heading with “Why restrict this?”, for most, but not all,
restriction lints. I left alone the ones whose placement in the
restriction group is more incidental.
In order to make this make sense, I had to remove the “It isn't, but”
texts from the contents of the sections. Sometimes further changes
were needed, or there were obvious fixes to make, and I went ahead
and made those changes without attempting to split them into another
commit, even though many of them are not strictly necessary for the
“Why restrict this?” project.
Modify lint pass note for consistency with the book
This PR:
- removes the note which appears when an early lint pass is created using `cargo dev new_lint`.
- adds a note that encourages contributors to use an early pass unless type information is needed if a late lint pass is created using `cargo dev new_lint`.
Late pass remains the default value if no pass is specified as most lints use late pass.
Closes#12595
changelog: none
