diff options
| author | bors <bors@rust-lang.org> | 2020-12-09 13:54:07 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2020-12-09 13:54:07 +0000 |
| commit | fa55f668e5ea5388ec98b9340969527252239151 (patch) | |
| tree | 88d6be7cb33c71030f3314ba6943481a53db25ef /compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp | |
| parent | cc03ee6702053ded253c3656cbd02f0bfdf25c73 (diff) | |
| parent | c2946402ffb5edde461b5047213e56b4e1500ec8 (diff) | |
| download | rust-fa55f668e5ea5388ec98b9340969527252239151.tar.gz rust-fa55f668e5ea5388ec98b9340969527252239151.zip | |
Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash, r=wesleywiser
Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode, we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache, and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache, we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However, PR #74967 didn't do this in all cases, leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
