Encode spans relative to the enclosing item

[cjgillot]

Proposal

Right now, spans are hashed for incremental compilation using their byte offset in their respective file. As a consequence, each time a function is modified, all the code following it in the same file must be recompiled.

The aim of this MCP is to avoid recomputing queries when code is moved without modification.

This is achieved by :

1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. creating a source_span(LocalDefId) returning the absolute span;
4. marking a dependency to the source_span(LocalDefId) query when we translate a span from the short (Span) representation to its explicit (SpanData) representation.

Since all client code uses Span, step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the source_span(LocalDefId). As this query returns the actual absolute span of the parent item, any source code motion that changes the absolute byte position of a node will either:

• modify the distance to the parent's beginning, so change the relative span's hash;
• dirty source_span, and trigger the incremental recomputation of all code that depends on the span's absolute byte position.

With this scheme, I believe the dependency tracking to be accurate.

Mentors or Reviewers

@petrochenkov started to review the first PR.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[estebank]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted