Rollup of 5 pull requests
Successful merges:
- #119322 (Couple of random coroutine pass simplifications)
- #119374 (Italicise "bytes" in the docs of some `Vec` methods)
- #119388 (rustc_lint: Prevent triplication of various lints)
- #119406 (Add non-regression test for ATPIT ICE #114325)
- #119410 (Rename test to be more descriptive)
r? `@ghost`
`@rustbot` modify labels: rollup
rustc_lint: Prevent triplication of various lints
Prevent triplication of various lints. The triplication happens because we run the same lint three times (or less in some cases):
* In `BuiltinCombinedPreExpansionLintPass`
* In `BuiltinCombinedEarlyLintPass`
* In `shallow_lint_levels_on()`
Only run the lints one time by checking the `lint_added_lints` bool.
Set your GitHub diff setting to ignore whitespaces changes when reviewing this PR, since I had to enclose a block inside an if.
Closes#73301
(I found this while exploring the code related to [this](https://github.com/rust-lang/rust/pull/119251#discussion_r1435677330) comment.)
Italicise "bytes" in the docs of some `Vec` methods
On a cursory read it's easy to miss that the limit is in terms of bytes not no. of elements. The italics should help with that.
Fixes#119149
Remove usage of deprecated `missing-tools` bootstrap flag
This PR removes the usage of `--enable-missing-tools` in CI, as this config option is no longer used. It also removes `dist.missing-tools` config completely.
Let me know which commits should I remove (if any).
Fixes: https://github.com/rust-lang/rust/issues/79249
r? `@onur-ozkan`
Also walk bindings created by if-let guards
This change makes the `unused_variables` lint pick up unused bindings created by if-let guards.
Fixes#119383
coverage: Avoid a possible query stability hazard in `CoverageCounters`
#119252 revealed a possible query stability hazard in `CoverageCounters`: we iterate over the entries of an `FxHashMap` in a way that allows the iteration order to potentially affect the relative creation order of MIR blocks.
I'm not sure whether there's an actual stability problem or not in practice, but it's certainly a hazard, and I don't see any reason not to switch over to `FxIndexMap` to avoid potential issues.
---
This can either be merged on its own, or incorporated into #119252.
cc `@Enselic`
r? `@cjgillot`
Merge Coroutine lowering functions
Instead of having separate `make_async/etc_expr` functions, this merges them them into one, reducing code duplication a bit.
Use `Pat::walk_always` instead of manual walk
It's also a bit faster, but I doubt that it will have a noticeable perf impact. Mostly doing it because it's shorter and nicer.
utilize the unused `llvm-tools` option
This field was not functioning as described in its comment in `config.example.toml`. Also, updated the default value to `true` to keep the bootstrapping behavior as it was before.
cc `@Zalathar`
Remove movability from `TyKind::Coroutine`
There's no reason to store movability in the generator struct directly. It is computed from the HIR, and can be pulled into a query to access when necessary.
Prevent multiple 'ignored unless specified at crate level' lints. The
multiplication happens because we run the same lint three times:
* In BuiltinCombinedEarlyLintPass
* In BuiltinCombinedPreExpansionLintPass
* In shallow_lint_levels_on
Only run the lint one time by checking the `lint_added_lints` bool.
Rollup of 5 pull requests
Successful merges:
- #119331 (rustdoc-search: count path edits with separate edit limit)
- #119359 (Simplify Parser::ident_or_error)
- #119376 (Add regression test for #106630)
- #119379 (Update `parse_seq` doc)
- #119380 (Don't suggest writing a bodyless arm if the pattern can never be a never pattern)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't suggest writing a bodyless arm if the pattern can never be a never pattern
#118527 enabled arms to be bodyless for never patterns ; this PR removes the `,` and `}` suggestions for patterns that could never be never patterns.
Add regression test for #106630
This PR adds a regression test for #106630. I was unsure where exactly to place the test or how to test it locally so please let me know if I should change something.
rustdoc-search: count path edits with separate edit limit
Avoids strange-looking results like this one, where the path component seems to be ignored:
Since the two are counted separately elsewhere, they should get their own limits, too. The biggest problem with combining them is that paths are loosely checked by not requiring every component to match, which means that if they are short and matched loosely, they can easily find "drunk typist" matches that make no sense, like this old result:
std::collections::btree_map::itermut matching slice::itermut
maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
editDistance("std", "slice") = 4
editDistance("itermut", "itermut") = 0
4 + 0 <= 4 PASS
Of course, `slice::itermut` should not match stuff from btreemap. `slice` should not match `std`.
The new result counts them separately:
maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
editDistance("std", "slice") = 4
4 <= 1 FAIL
Effectively, this makes path queries less "typo-resistant". It's not zero, but it means `vec` won't match the `v1` prelude.
This commit also adds substring matching to paths. It's stricter than the substring matching in the main part, but loose enough that what I expect to match does.
Queries without parent paths are unchanged.
