rustc_metadata: Encode list of all crate's traits into metadata
While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive, something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree.
This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors, which execute the `all_traits` query for better diagnostics).
compiletest: Remove some vestigial code
The `check_lines` header is no longer parsed as a header, but instead inside the debuginfo tests. I believe this was changed in #13726.
The crate name is already set in Cargo.toml. The comment says there is
some logic in the compiler that reads #![crate_name] and not
--crate-name, but I can't find it. Removing it seems to work fine.
Rollup of 7 pull requests
Successful merges:
- #92075 (rustdoc: Only special case struct fields for intra-doc links, not enum variants)
- #92118 (Parse and suggest moving where clauses after equals for type aliases)
- #92237 (Visit expressions in-order when resolving pattern bindings)
- #92340 (rustdoc: Start cleaning up search index generation)
- #92351 (Add long error explanation for E0227)
- #92371 (Remove pretty printer space inside block with only outer attrs)
- #92372 (Print space after formal generic params in fn type)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Print space after formal generic params in fn type
Follow-up to #92238 fixing one of the FIXMEs.
```rust
macro_rules! repro {
($ty:ty) => {
stringify!($ty)
};
}
fn main() {
println!("{}", repro!(for<'a> fn(&'a u8)));
}
```
Before: `for<'a>fn(&'a u8)`
After: `for<'a> fn(&'a u8)`
The pretty printer's `print_formal_generic_params` already prints formal generic params correctly with a space, we just need to call it when printing BareFn types instead of reimplementing the printing incorrectly without a space.
83b15bfe1c/compiler/rustc_ast_pretty/src/pprust/state.rs (L1394-L1400)
Visit expressions in-order when resolving pattern bindings
[edited:] Visit the pattern's sub-expressions before defining any bindings.
Otherwise, we might get into a case where a Lit/Range expression in a pattern has a qpath pointing to a Ident pattern that is defined after it, causing an ICE when lowering to HIR. I have a more detailed explanation in the issue linked.
Fixes#92100
Parse and suggest moving where clauses after equals for type aliases
~Mostly the same as #90076, but doesn't make any syntax changes.~ Whether or not we want to land the syntax changes, we should parse the invalid where clause position and suggest moving.
r? `@nikomatsakis`
cc `@petrochenkov` you might have thoughts on implementation
rustdoc: Only special case struct fields for intra-doc links, not enum variants
Variants are already handled by `resolve_str_path_error`, rustdoc doesn't need to consider them separately. Thanks `@camelid` for catching this!
Eventually I'd like to fix the "combine this with `variant_field`" comment but that needs `resolve_field` to take a `ty_res` parameter to avoid it being super hacky (cc https://github.com/rust-lang/rust/issues/83761#issuecomment-813026026).
r? `@camelid`
rustdoc: Remove `String` allocation in iteration in `print_generic_bounds`
(I realized only after making the commit that maybe I shouldn't refer to iteration as looping, but it's close enough)
The string representation of a `clean::GenericBound` instance (evaluated [here](https://github.com/rust-lang/rust/blob/master/src/librustdoc/html/format.rs#L397)) is deterministic for a given `self` (the instance), `cx` and `f`, and since `cx` and `f` are constant (as far as I can tell) for a given invocation of `print_generic_bounds`, `self` is the determining factor. Therefore, using the data in `self` shouldn't differ in effect from using its string representation.
Given the totality of the function calls needed to evaluate the string representation as well as the actual allocation, at the very least, this shouldn't negatively affect performance.
This issue was fixed using a hacky recursion "fuel" argument, but the
issue was never minimized nor was a regression test added. The
underlying bug is still unfixed, so this test should help with fixing it
and removing the `recurse` hack.
Limit the ``[`identity_op`]`` lint to integral operands.
changelog: limit ``[`identity_op`]`` to integral operands
In the ``[`identity_op`]`` lint, if the operands are non-integers, then the lint is likely
wrong.
