Hash ExpnData without absolute positions [isolated: -3.8% incr-patched, serde -18%, 0 regressions] - #90
Closed
xmakro wants to merge 2 commits into
Closed
Hash ExpnData without absolute positions [isolated: -3.8% incr-patched, serde -18%, 0 regressions]#90xmakro wants to merge 2 commits into
xmakro wants to merge 2 commits into
Conversation
This was referenced Aug 4, 2026
Draft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ExpnDatahashed the absolute positions of its call site and def site.ExpnHashfeeds theSyntaxContexthash of every macro-expanded span, so one inserted line at the top of a file changed the hash of every expansion below it and reddened all macro-expanded HIR in the crate.The manual
StableHashimpl now hashes the two sites' hygiene context and skips their positions. Uniqueness comes fromupdate_disambiguator, which numbers colliding expansions in expansion order. An edit that reorders identical expansions is a conservative miss.Unsound as written, do not merge
The call-site position is itself a codegen input:
walk_chain_collapsedcollapses debuginfo toExpnData::call_site, and#[track_caller]materializesLocationfromsource_callsite(). Both read hygiene data untracked, so their only dep-graph coverage was the call-site position insideExpnHash. With that removed, shifting a macro invocation leavesoptimized_mirand downstream CGUs green, and reused object code keeps the old line numbers.Repro (stage2 of this branch vs its base, same config):
foo::<u8>instantiates into main's CGU, whose remaining inputs are untouched by the edit. After the incremental rebuild this branch panics at the stalem.rs:8:1while a fresh build of the same source reportsm.rs:9:1. The base compiler reportsm.rs:9:1both ways. Collapsed DWARF line info goes stale the same way.#[rustc_clean]confirms the flip: on the base compiler the edit dirtieshir_owner(foo)andoptimized_mir(foo), on this branch both stay clean.Single-file tests and the incremental suite miss this because any edit changes the enclosing module's span, which reddens that module's own CGU and re-runs codegen, hiding the stale values. The cross-module instantiation above is the shape that escapes.
Since panic locations and debug line tables are observable outputs derived from the call-site position, codegen reuse must be invalidated when that position changes. A position-free
ExpnHashcannot provide that on its own; the analysis-level reuse this PR buys is real, but it needs a separate mechanism to cover the codegen reads before it can land.