Rollup of 4 pull requests
Successful merges:
- #136183 (Update iterator.rs to use arrays by value)
- #139966 (coverage: Only merge adjacent coverage spans)
- #140692 (Rename `graph::implementation::Graph` to `LinkedGraph`)
- #140703 (Handle PR not found in post-merge workflow)
r? `@ghost`
`@rustbot` modify labels: rollup
fixrust-lang/rust-clippy#13637
As suggested in the PR above, we should not lint enum variants
containing matching path names.
changelog: [`item_name_repetitions`]: exclude enum variants with
identical path components
Rename `graph::implementation::Graph` to `LinkedGraph`
One of the more confusing parts of the `rustc_data_structures::graph` module is this mysteriously-named “Graph” type, which turns out to be an older standalone graph implementation that predates the traits used by the rest of the graph module.
This graph type is still used in a couple of places (for reporting certain lifetime errors, and by certain debugging/test-only checks of the query dependency graph), but hasn't had much attention in years.
This PR renames that old graph type from `implementation::Graph` to `linked_graph::LinkedGraph` to give it a more distinct identity (and make existing uses easier to find), and adds some notes to gently discourage any further use in new code.
No functional change.
coverage: Only merge adjacent coverage spans
For a long time, coverage instrumentation has automatically “merged” spans with the same control-flow into a smaller number of larger spans, even when the spans being merged are not overlapping or adjacent. This causes any source text between the original spans to be included in the merged span, which is then associated with an execution count when shown in coverage reports.
That approach causes a number of problems:
- The intervening source text can contain all sorts of things that shouldn't really be marked as executable code (e.g. nested items, parts of macro invocations, long comments). In some cases we have complicated workarounds (e.g. bucketing to avoid merging spans across nested items), but in other cases there isn't much we can do.
- Merging can have aesthetically weird effects, such as including unbalanced parentheses, because the merging process doesn't really understand what it's doing at a source code level.
- It generally leads to an accumulation of piled-on heuristics and special cases that give decent-looking results, but are fiendishly difficult to modify or replace.
Therefore, this PR aims to abolish the merging of non-adjacent coverage spans.
The big tradeoff here is that the resulting coverage metadata (embedded in the instrumented binary) tends to become larger, because the overall number of distinct spans has increased. That's unfortunate, but I see it as the inevitable cost of cleaning up the messes and inaccuracies that were caused by the old approach. And the resulting spans do tend to be more accurate to the program's actual control-flow.
---
The `.coverage` snapshot changes give an indication of how this PR will affect user-visible coverage reports. In many cases the changes to reporting are minor or even nonexistent, despite substantial changes to the metadata (as indicated by `.cov-map` snapshots).
---
try-job: aarch64-gnu
fixes#14413
add allow_unused config to missing_docs_in_private_items for underscored
field
changelog: [`missing_docs_in_private_items`]: add allow_unused config to
missing_docs_in_private_items for underscored field
Explaination (quoted from the issue's author): When writing structures
that must adhere to a specific format (such as memory mapped I/O
structures) there are inevitably fields that are "reserved" by
specifications and thus need no documentation. In cases where private
docs are preferred but reserved fields need no explanation, having to
#[allow/expect] this lint removes the ability to check for otherwise
used fields' documentation.
Name them more consistently, descriptively and appropriately.
Move large error reporting methods into the dedicated error module to
make the happy paths in HIR ty lowering more legible.
Rollup of 4 pull requests
Successful merges:
- #140135 (Unify sidebar buttons to use the same image)
- #140632 (add a test for issue rust-lang/rust#81317)
- #140658 (`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching)
- #140681 (Don't ignore compiler stderr in `lib-defaults.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when `deref_patterns` is enabled. In particular, string literals can now match on `String`, subsuming the functionality of the `string_deref_patterns` feature.
More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and `const STR: &'static str` wouldn't be able to match on a `String` unless a rule was added to let it be used where a `str` is expected, similar to what #140028 did for literals).
This also allows string and byte string patterns to match on mutable references, following up on https://github.com/rust-lang/rust/pull/140028#discussion_r2053927512. Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel `&mut`s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. See [`byte-string-type-errors.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-4a0dd9b164b67c706751f3c0b5762ddab08bcef05a91972beb0190c6c1cd3706) for how the diagnostics look.
At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by [`const-pats-do-not-mislead-inference.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-19afc05b8aae9a30fe4a3a8c0bc2ab2c56b58755a45cdf5c12be0d5e83c4739d). To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: [(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1869744cb9cdfed71a686990aadf9fe1). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).
Tracking issue for deref patterns: #87121
r? `@oli-obk`
cc `@Nadrieril`
