Encode spans relative to the enclosing item -- enable on nightly by cjgillot · Pull Request #84762 · rust-lang/rust (original) (raw)

Follow-up to #84373 with the flag -Zincremental-relative-spans set by default.

This PR seeks to remove one of the main shortcomings of incremental: the handling of spans.
Changing the contents of a function may require redoing part of the compilation process for another function in another file because of span information is changed.
Within one file: all the spans in HIR change, so typechecking had to be re-done.
Between files: spans of associated types/consts/functions change, so type-based resolution needs to be re-done (hygiene information is stored in the span).

The flag -Zincremental-relative-spans encodes local spans relative to the span of an item, stored inside the source_span query.

Trap: stashed diagnostics are referenced by the "raw" span, so stealing them requires to remove the span's parent.

In order to avoid too much traffic in the span interner, span encoding uses the ctxt_or_tag field to encode:

• the parent when the SyntaxContext is 0;
• the SyntaxContext when the parent is None.
  Even with this, the PR creates a lot of traffic to the Span interner, when a Span has both a LocalDefId parent and a non-root SyntaxContext. They appear in lowering, when we add a parent to all spans, including those which come from macros, and during inlining when we mark inlined spans.

The last commit changes how queries of LocalDefId manage their cache. I can put this in a separate PR if required.

Possible future directions:

• validate that all spans are marked in HIR validation;
• mark macro-expanded spans relative to the def-site and not the use-site.