dynamically check dep-graph write patterns
Closed this issue · 2 comments
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.
A previous branch that inserted some tombstones to prevent write-after-read: https://github.com/nikomatsakis/rust/tree/incr-comp-tombstone
we decided it would be better to just remove the bad methods, see #40614