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

dynamically check dep-graph write patterns #40305

Closed
nikomatsakis opened this issue Mar 6, 2017 · 2 comments
Closed

dynamically check dep-graph write patterns #40305

nikomatsakis opened this issue Mar 6, 2017 · 2 comments
Labels
A-incr-comp Area: Incremental compilation E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Mar 6, 2017

NB: Part of the roadmap issue on incremental compilation.

We should monitor the dep-graph reads/writes for various bad patterns that may lead to bugs in the output:

  • whenever we see a read from node X, there should never be a subsequent write
    • if X corresponds to a missing key in the map, this requires tracking a "poison set"
    • otherwise we can just forbid a write to an already existing key
    • the push() method should be removed
  • reading from the set of keys should probably be considered a read of Krate, and we should refactor tasks to allow that read

I tried this and ran into some problems. It's worth taking another stab. I am marking this as mentor -- I would be happy to work with someone who is interested in pursuing it. This will be a bit of an "exploratory" project, so the best thing would be contact me on IRC (nmatsakis; privmsg me and I'll respond as soon as I see it).

The first steps, however, would be to modify the DepTrackingMap, e.g. to "freeze" a key when get() returns None. I would probably do this tracking only if #[cfg(debug_assertions)] are enabled.

@nikomatsakis nikomatsakis added A-incr-comp Area: Incremental compilation E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2017
@nikomatsakis
Copy link
Contributor Author

A previous branch that inserted some tombstones to prevent write-after-read: https://github.com/nikomatsakis/rust/tree/incr-comp-tombstone

@nikomatsakis
Copy link
Contributor Author

we decided it would be better to just remove the bad methods, see #40614

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 E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. 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