Skip to content
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

Closed
nikomatsakis opened this issue Jul 21, 2016 · 0 comments
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
Copy link
Contributor

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.

@nikomatsakis 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.
Projects
None yet
Development

No branches or pull requests

1 participant