Repository navigation
Incremental compilation: Be smart about hashing spans #33888
Description
Activity
Indeed. I think that spans can be significant in other ways, such as macros that expand to the current filename/linenumber--ah but I guess those are desugaring in the HIR anyhow.
OTOH, the
Spanmay not change, but information extracted from it might.@nikomatsakis I think we can track all users of information from a
Spanthat can affect code generation.@michaelwoerister For LLVM debuginfo, we could actually transform the debug info metadata nodes to correspond to new locations, although the C API might not have the facilities to do so.
I think comment changes would otherwise trigger full rebuilds, which we don't want to, I don't think.@eddyb besides debuginfo, what users can you think of?
@nikomatsakis I was referring to the syntax extension ones you mentioned, although at this moment that doesn't make much sense, so nevermind.
The way the code-map is currently set up, all source files of a crate and its dependencies are layout into one big "address space", e.g:
That means that adding a byte to
a.rswill change all addresses inb.rsandc.rs. Consequently, were we to incorporate the verbatimBytePosvalues in theSpanscontained in the AST, small changes would cause recompilations of seemingly unrelated files.Thus, we need to find a more stable way of hashing spans, like expanding them to
file-name:line:col(or not hash them at all, if we don't compile with debuginfo).cc @nikomatsakis