You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Properly track virtual path remapping during incremental compilation
When the `rust-src` component is installed, rustc will automatically
remap paths from the standard library to point into the local system.
The target filesystem location is stored in
`tcx.sess.real_rust_source_base_dir`
This is a form of global state that's not tracked by the incremental
compilation system, which can lead to ICEs when the `rust-src` component
is added or removed between compilation sessions.
This PR fixes several bugs in incremental compilation
* We now hash `real_rust_source_base_dir` when computing a crate hash,
since it affects any spans that we import from foreign crates (e.g.
via macros or inlining).
* The `crate_hash` and `host_crate_hash` quereis now return a wrapper
around `Svh`, which also hashes the value of
`real_rust_source_base_dir` in the *current* compilation session.
This reflects the fact that changes to this value affect how we decode
values from all foreign crates.
* We now properly re-compute the `name_hash` of an imported `SourceFile`
when we remap a path.
There was a test for this kind of issue, but it was broken when the
standard library was moved to `library/std`, and was no longer actually
testing anything. To ensure that this doesn't happen again, I've
modified the test to build a binary that outputs a remapped standard
library path (via a panic), and verifies that the precense of `rust-src`
during compilation correctly affects the output of the compiled binary.
0 commit comments