Closed
Description
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.