macro_rules: Preserve all metavariable spans in a global side table
This PR preserves spans of `tt` metavariables used to pass tokens to declarative macros.
Such metavariable spans can then be used in span combination operations like `Span::to` to improve all kinds of diagnostics.
Spans of non-`tt` metavariables are currently kept in nonterminal tokens, but the long term plan is remove all nonterminal tokens from rustc parser and rely on the proc macro model with invisible delimiters (#114647, #67062).
In particular, `NtIdent` nonterminal (corresponding to `ident` metavariables) becomes easy to remove when this PR lands (#119412 does it).
The metavariable spans are kept in a global side table keyed by `Span`s of original tokens.
The alternative to the side table is keeping them in `SpanData` instead, but the performance regressions would be large because any spans from tokens passed to declarative macros would stop being inline and would work through span interner instead, and the penalty would be paid even if we never use the metavar span for the given original span.
(But also see the comment on `fn maybe_use_metavar_location` describing the map collision issues with the side table approach.)
There are also other alternatives - keeping the metavar span in `Token` or `TokenTree`, but associating it with `Span` itsel is the most natural choice because metavar spans are used in span combining operations, and those operations are not necessarily tied to tokens.
Remove const_prop.rs
Removed const_prop.rs and moved its contents to const_prop_lint.rs and dataflow_const_prop.rs where they are used.
const_prop.rs does not actually do any const propagation any more. After #116012 all it contains is code that is used by const_prop_lint.rs and one macro that is used by dataflow_const_prop.rs. So it made sense to just move it to those two places and remove this file.
Add help to `hir_analysis_unrecognized_intrinsic_function`
To help remind forgetful people like me what step they forgot.
(If this just ICE'd, https://github.com/rust-lang/compiler-team/issues/620 style, the stack trace would point me here, but since there's a "nice" error that information is lost.)
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
Rollup of 7 pull requests
Successful merges:
- #120526 (rustdoc: Correctly handle long crate names on mobile)
- #121100 (Detect when method call on argument could be removed to fulfill failed trait bound)
- #121160 (rustdoc: fix and refactor HTML rendering a bit)
- #121198 (Add more checks for `unnamed_fields` during HIR analysis)
- #121218 (Fix missing trait impls for type in rustc docs)
- #121221 (AstConv: Refactor lowering of associated item bindings a bit)
- #121237 (Use better heuristic for printing Cargo specific diagnostics)
r? `@ghost`
`@rustbot` modify labels: rollup
AstConv: Refactor lowering of associated item bindings a bit
Split off from #119385 as discussed, namely the first two commits (modulo one `FIXME` getting turned into a `NOTE`).
The second commit removes `astconv::ConvertedBinding{,Kind}` in favor of `hir::TypeBinding{,Kind}`. The former was a — in my opinion — super useless intermediary. As you can tell from the diff, its removal shaves off some code. Furthermore, yeeting it will make it easier to implement the type resolution fixes in #119385.
Nothing in this PR should have any semantic effect.
r? `@compiler-errors`
<sub>**Addendum** as in #118668: What I call “associated item bindings” are commonly referred to as “type bindings” for historical reasons. Nowadays, “type bindings” include assoc type bindings, assoc const bindings and RTN (return type notation) which is why I prefer not to use this outdated term.</sub>
Add more checks for `unnamed_fields` during HIR analysis
Fixes#121151
I also found that we don't prevent enums here so
```rs
#[repr(C)]
#[derive(Debug)]
enum A {
#[default]
B,
C,
}
#[repr(C)]
#[derive(Debug)]
struct D {
_: A,
}
```
leads to an ICE on an `self.is_struct() || self.is_union()` assertion, so fixed that too.
Properly deal with weak alias types as self types of impls
Fixes#114216.
Fixes#116100.
Not super happy about the two ad hoc “normalization” implementations for weak alias types:
1. In `inherent_impls`: The “peeling”, normalization to [“WHNF”][whnf]: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. [#97974](https://github.com/rust-lang/rust/pull/97974) followed the same approach.
2. In `constrained_generic_params`: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize *weak* alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective.
Both have ad hoc overflow detection mechanisms.
**Coherence** is handled in #117164.
r? `@oli-obk` or types
[whnf]: https://en.wikipedia.org/wiki/Lambda_calculus_definition#Weak_head_normal_form
The moment we get a candidate without guard, the return block becomes a
fresh block linked to nothing. So we can keep assigning a fresh block
every iteration to reuse the `next_prebinding` logic.
Fix `cfg(target_abi = "sim")` on `i386-apple-ios`
Since https://github.com/rust-lang/rust/issues/80970 is stabilizing, I went and had a look, and found that the result was wrong on `i386-apple-ios`.
r? rust-lang/macos
Use fulfillment in next trait solver coherence
Use fulfillment in the new trait solver's `impl_intersection_has_impossible_obligation` routine. This means that inference that falls out of processing other obligations can influence whether we can determine if an obligation is impossible to satisfy. See the committed test.
This should be completely sound, since evaluation and fulfillment both respect intercrate mode equally.
We run the risk of breaking coherence later if we were to change the rules of fulfillment and/or inference during coherence, but this is a problem which affects evaluation, as nested obligations from a trait goal are processed together and can influence each other in the same way.
r? lcnr
cc #114862
Also changed obligationctxt -> fulfillmentctxt because it feels kind of redundant to use an ocx here. I don't really care enough and can change it back if it really matters much.
errors: only eagerly translate subdiagnostics
Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context.
This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change).
r? ```@nnethercote```
