Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
bf1a4e3 to
50ba28a
Compare
This comment has been minimized.
This comment has been minimized.
50ba28a to
68660f2
Compare
This comment has been minimized.
This comment has been minimized.
68660f2 to
1f2a9e3
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
1f2a9e3 to
e1094a1
Compare
e1094a1 to
d9dd28d
Compare
This comment has been minimized.
This comment has been minimized.
d9dd28d to
decf8a0
Compare
|
r? @nnethercote rustbot has assigned @nnethercote. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Fwiw, I think this could also fix a nasty cache corruption bug I ran into when a rustc compile gets interrupted with incremental and opt-level >= 1. I had my agent whip up a quick repro here for anyone interested in digging deeper: https://github.com/lewisl9029/rustc-incremental-lto-repro TL;DR: it can either show cryptic errors that don't match the source, or (worse) successfully build a new binary that doesn't match the source, depending on what gets mixed up in the cache from unintentionally overwriting hardlinks pointing to previous finalized session state without a new finalized session taking its place (due to getting interrupted, even from just a ctrl+c, no SIGKILL needed). Rebuilding doesn't fix the issue either, only a cargo clean will. Originally encountered on 1.94.1, but still repros on 1.98.0. |
This comment has been minimized.
This comment has been minimized.
6d15619 to
4f85d86
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4f85d86 to
12df0c5
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
12df0c5 to
3194c7f
Compare
This comment has been minimized.
This comment has been minimized.
be97457 to
6bae246
Compare
c77153b to
49c263e
Compare
…=khyperia Depend on lockfiles to prevent GC of the current session Instead of manually skipping it right before the remove_dir. This will be simpler once we stop immediately copying from the old incr comp dir. Previously this wasn't possible due to the usage of process-based fcntl locking, but I added proper fd-based locking recently in rust-lang#162602. Will probably simplify rust-lang#159287 a bit.
…=khyperia Depend on lockfiles to prevent GC of the current session Instead of manually skipping it right before the remove_dir. This will be simpler once we stop immediately copying from the old incr comp dir. Previously this wasn't possible due to the usage of process-based fcntl locking, but I added proper fd-based locking recently in rust-lang#162602. Will probably simplify rust-lang#159287 a bit.
Rollup merge of #162952 - bjorn3:incr_comp_locking_change, r=khyperia Depend on lockfiles to prevent GC of the current session Instead of manually skipping it right before the remove_dir. This will be simpler once we stop immediately copying from the old incr comp dir. Previously this wasn't possible due to the usage of process-based fcntl locking, but I added proper fd-based locking recently in #162602. Will probably simplify #159287 a bit.
49c263e to
71716be
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Rather than copying the old incr comp dir and then modifying it. This saves a copy/hardlink for files that are modified. And it removes the need for accurate work product tracking to avoid accumulating cruft, which is non-trivial. We don't accurately track the pre-LTO bitcode files for ThinLTO for example.
71716be to
9c951e2
Compare
| //! The exact same scheme is also used when reading the metadata hashes file | ||
| //! from an extern crate. When a crate is compiled, the hash values of its | ||
| //! metadata are stored in a file in its session directory. When the | ||
| //! compilation session of another crate imports the first crate's metadata, | ||
| //! it also has to read in the accompanying metadata hashes. It thus will access | ||
| //! the finalized session directory of all crates it links to and while doing | ||
| //! so, it will also place a read lock on that the respective session directory | ||
| //! so that it won't be deleted while the metadata hashes are loaded. |
There was a problem hiding this comment.
This section has long been outdated. We don't ever access the incr comp cache for other crates nowadays. Instead we just read the crate metadata like usual through eval_always queries.
|
@rustbot ready |
View all comments
Rather than copying the old incr comp dir and then modifying it. This saves a copy/hardlink for files that are modified. And it removes the need for accurate work product tracking to avoid accumulating cruft, which is non-trivial. We don't accurately track the pre-LTO bitcode files for ThinLTO for example.
Part of rust-lang/compiler-team#908