optimized_mir unstable fingerprint when compiling rustc
#85197
Assignees
Labels
Comments
Aaron1011
added
C-bug
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 14, 2021
…chaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes rust-lang#85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache, but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache, we will decode it with a 'dummy' location, but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`), the metadata encoder would treat it as a normal span, encoding the `SyntaxContext`. As a result, the final span encoded to the metadata would change across sessions, even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid, while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate, we execute a foreign query, decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far, this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache, without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location, along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location, we preserve its `SyntaxContext`. 4. We recompile the second crate, again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged, but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing, resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext`, and encode location information for spans with a non-dummy location.
Mark-Simulacrum
pushed a commit
to Mark-Simulacrum/rust
that referenced
this issue
Jun 11, 2021
Fixes rust-lang#85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache, but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache, we will decode it with a 'dummy' location, but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`), the metadata encoder would treat it as a normal span, encoding the `SyntaxContext`. As a result, the final span encoded to the metadata would change across sessions, even if the crate itself was unchanged. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext`, and encode location information for spans with a non-dummy location.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #84970 (comment) and #84960 for other instances of this happening
I've managed to reliably reproduce an
optimized_mir'unstable fingerprint' issue when building rustc. Reproduction steps:./x.py cleanfollowed by./x.py build --stage 1 library/std./x.py build --stage 1 library/stdYou should observe the following error (my
config.tomlis included in the gist)https://gist.github.com/Aaron1011/7eec8b2c584f8c9d2195f521c13d4f01
The text was updated successfully, but these errors were encountered: