incr.comp.: Remove DepGraph::write() and its callers#42192
incr.comp.: Remove DepGraph::write() and its callers#42192bors merged 1 commit intorust-lang:masterfrom
Conversation
nikomatsakis
left a comment
There was a problem hiding this comment.
Looks good, left a nit.
src/librustc/ty/maps.rs
Outdated
There was a problem hiding this comment.
I feel like we should move this read() into the body of try_get_with; basically into the most "fundamental" spot. (In that case, you could only execute it if the cache lookup succeeds, which I think makes the overall logic of this code cleaner anyhow.)
There was a problem hiding this comment.
Hm, but a force does not give you access to the value...
|
(r=me with that change) |
src/librustc/ty/maps.rs
Outdated
There was a problem hiding this comment.
Can we just use FxHashMap directly in the macro and perhaps even avoid having a trait for Key/Value altogether?
There was a problem hiding this comment.
I like the idea but that would complicate the define_map_struct macro. Since all of this will be refactored in the near future anyway, I think it's OK to do this in a later PR.
src/librustc/ty/maps.rs
Outdated
There was a problem hiding this comment.
I'm wondering if there's a way to get rid of the RefCell's here - perhaps a type with a very simple foolproof API based on Cell - something that requires a trait implemented for Copy types and Rc (which can't run arbitrary code when cloning), perhaps? It would probably have to be in its own module to prevent accidental bypass.
There was a problem hiding this comment.
The advantage being that we would get rid of the runtime check? Sounds intriguing :)
There was a problem hiding this comment.
I always expected it to be possible, it's just a matter of reducing the footprint to introduce a sound abstraction.
09064a7 to
d68ccf6
Compare
d68ccf6 to
c150301
Compare
|
@bors r=nikomatsakis Added a comment about the |
|
📌 Commit c150301 has been approved by |
…, r=nikomatsakis incr.comp.: Remove DepGraph::write() and its callers After months of yak shaving, we are finally there `:)` The existence of `DepGraph::write()` was one of the two main ways for introducing cycles into the dep-graph -- something we need to avoid in the future. The other way, re-opening nodes to add more edges, is next on the list. r? @nikomatsakis
|
☀️ Test successful - status-appveyor, status-travis |
After months of yak shaving, we are finally there
:)The existence of
DepGraph::write()was one of the two main ways for introducing cycles into the dep-graph -- something we need to avoid in the future. The other way, re-opening nodes to add more edges, is next on the list.r? @nikomatsakis