Incremental compilation: Be smart about hashing spans

[michaelwoerister]

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:

    a.rs         b.rs           c.rs
|----------|--------------|--------------|
0         100            220            340 bytes

That means that adding a byte to a.rs will change all addresses in b.rs and c.rs. Consequently, were we to incorporate the verbatim BytePos values in the Spans contained 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

[nikomatsakis]

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.

[eddyb]

OTOH, the Span may not change, but information extracted from it might.

@nikomatsakis I think we can track all users of information from a Span that 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.

[nikomatsakis]

@eddyb besides debuginfo, what users can you think of?

[eddyb]

@nikomatsakis I was referring to the syntax extension ones you mentioned, although at this moment that doesn't make much sense, so nevermind.