Skip to content

dynamically check dep-graph write patterns #40305

Closed
@nikomatsakis

Description

@nikomatsakis

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-incr-compArea: Incremental compilationE-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions