incr.comp.: Current serialization logic for Spans messes with fingerprint stability

[michaelwoerister]

At the moment, when we serialize a Span, we drop any macro expansion information, that is, we just keep the lo and hi fields and drop the ctxt field. Consequently, when we load something with a Span from disk (like a piece of MIR, for example), and that Span in there had a non-zero ctxt before being stored to disk, then we get a different Fingerprint because we now have an empty ctxt.

I'm not sure whether this is harmless and could be ignored but it certainly messes with the otherwise very handy -Zincremental-verify-ich feature. I'd prefer if we found a way of making this completely accurate (e.g. by somehow serializing and then restoring Span expansion contexts).

cc @nikomatsakis

[nikomatsakis]

A thought: we could maybe erase the ctxt from spans out of MIR sometime during the optimization process, so that the initial hash also excludes the ctxt.

[michaelwoerister]

Since the same serialization routines are also used when serializing Spans in cached diagnostics -- a case where we don't want to lose any information -- we need to think of a way of restoring the expansion information.

[michaelwoerister]

This is partly addressed by #46301.

[michaelwoerister]

This has been solved.