Access query (DepKind) metadata through fields
This refactors the access to query definition metadata (attributes such as eval always, anon, has_params) and loading/forcing functions to generate a number of structs, instead of matching on the DepKind enum. This makes access to the fields cheaper to compile. Using a struct means that finding the metadata for a given query is just an offset away; previously the match may have been compiled to a jump table but likely not completely inlined as we expect here.
A previous attempt explored a similar strategy, but using trait objects in #78314 that proved less effective, likely due to higher overheads due to forcing dynamic calls and poorer cache utilization (all metadata is fairly densely packed with this PR).
This adjusts the `rustdoc` trait impl collection path to preserve `Deref` impls
from other crates. This adds a first pass to map all of the `Deref` type to
target edges and then recursively preserves all targets.
Optimize away some `fs::metadata` calls.
This also eliminates a use of a `Path` convenience function, in support
of #80741, refactoring `std::path` to focus on pure data structures and
algorithms.
Rollup of 7 pull requests
Successful merges:
- #79675 (Make sure rust-call errors occur correctly for traits)
- #80372 (Don't panic when an external crate can't be resolved)
- #80761 (handle generic trait methods in coverage-report tests)
- #80785 (rustc_ast_pretty: Remove `PrintState::insert_extra_parens`)
- #80791 (Fix type name in doc example for Iter and IterMut)
- #80794 (Use Option::map_or instead of `.map(..).unwrap_or(..)`)
- #80799 (Get rid of custom pretty-printing in rustdoc)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
handle generic trait methods in coverage-report tests
also make the generic function pattern more specific and remove the extra $ that fails the matching.
r? `@wesleywiser`
as this was failing the test of #76896
Don't panic when an external crate can't be resolved
This isn't actually a bug, it can occur when rustdoc tries to resolve a
crate that isn't used in the main code.
Fixes#72381.
r? `@kinnison` if you have time, otherwise `@Manishearth`
Make sure rust-call errors occur correctly for traits
Fixes#79669
Adds trait method resolution to the error, and adds UI tests to ensure it doesn't happen again. Opening as draft because I'm getting weird link errors from unrelated code on my machine, and want to see what CI thinks.
rustc_parse: Better spans for synthesized token streams
I think using the nonterminal span for synthesizing its tokens is a better approximation than using `DUMMY_SP` or the attribute span like #79472 did in `expand.rs`.
r? `@Aaron1011`
Improve wording of parse doc
Change:
```
`parse` can parse any type that...
```
to:
```
`parse` can parse into any type that...
```
Word `into` added to be more precise and in coherence with other parts of the doc.
Properly handle primitive disambiguators in rustdoc
Fixes#80559
r? ``@jyn514``
Is there a way to test that the generated intra-doc link is what I expect?
MIR Inline is incompatible with coverage
Fixes: #80060
Fixed by disabling inlining if `-Zinstrument-coverage` is set.
The PR also adds additional use cases to the coverage test for doctests.
r? `@wesleywiser`
cc: `@tmandry`
Stabilize slice::strip_prefix and slice::strip_suffix
These two methods are useful. The corresponding methods on `str` are already stable.
I believe that stablising these now would not get in the way of, in the future, extending these to take a richer pattern API a la `str`'s patterns.
Tracking PR: #73413. I also have an outstanding PR to improve the docs for these two functions and the corresponding ones on `str`: #75078
I have tried to follow the [instructions in the dev guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr). The part to do with `compiler/rustc_feature` did not seem applicable. I assume that's because these are just library features, so there is no corresponding machinery in rustc.
