-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid modifying incr-compilation directory unless compilation completes normally #34957
Labels
A-incr-comp
Area: Incremental compilation
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
nikomatsakis
added
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
A-incr-comp
Area: Incremental compilation
labels
Jul 21, 2016
eddyb
added a commit
to eddyb/rust
that referenced
this issue
Aug 23, 2016
…ing, r=nikomatsakis Implement synchronization scheme for incr. comp. directory This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`. The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so. Fixes rust-lang#32754 Fixes rust-lang#34957
eddyb
added a commit
to eddyb/rust
that referenced
this issue
Aug 23, 2016
…ing, r=nikomatsakis Implement synchronization scheme for incr. comp. directory This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`. The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so. Fixes rust-lang#32754 Fixes rust-lang#34957
bors
added a commit
that referenced
this issue
Aug 31, 2016
…crichton Implement synchronization scheme for incr. comp. directory This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`. The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so. Fixes #32754 Fixes #34957
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-incr-comp
Area: Incremental compilation
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
In #34956, we modify the incremental compilation directory a bit wantonly. For example, when first starting up, we will delete work products if it looks likes things have changed -- and we serialize the dep-graph and only later serialize the work-products file.
It seems to me it would be better if we avoided making changes until the end of compilation. In some cases, we might be able to avoid making changes altogether. For example, we could keep
.o
files -- even if they are dirty -- if errors are resulting, which would mean that if the changes are rolled back, compilation succeeds instantaneously.Similarly, we might serialize the dep-graph to a temp file and then serialize the work-products also to a temp file, and finally rename both files to their actual names once both are done.
The text was updated successfully, but these errors were encountered: