incr. comp.: Methods should have their own dep-graph nodes #36349
Comments
|
I think the right way to do this is to separate out impl/trait items altogether. I'm going to investigate a bit. |
|
FWIW there's some of this already happening on http://github.com/eddyb/rust/commits/lazy-start. EDIT: updated link after rebase. Also, |
|
I've been working on this. I'm getting close to having a working branch (I'm roughly at the point of getting In particular, @eddyb, it seems to me that separating out impl items from the trait is valuable no matter what changes we make, since otherwise changes to the impl item signatures cause the impl's hash to change, no? |
Separate impl items from the parent impl This change separates impl item bodies out of the impl itself. This gives incremental more resolution. In so doing, it refactors how the visitors work, and cleans up a bit of the collect/check logic (mostly by moving things out of collect that didn't really belong there, because they were just checking conditions). However, this is not as effective as I expected, for a kind of frustrating reason. In particular, when invoking `foo.bar()` you still wind up with dependencies on private items. The problem is that the method resolution code scans that list for methods with the name `bar` -- and this winds up touching *all* the methods, even private ones. I can imagine two obvious ways to fix this: - separating fn bodies from fn sigs (#35078, currently being pursued by @flodiebold) - a more aggressive model of incremental that @michaelwoerister has been advocating, in which we hash the intermediate results (e.g., the outputs of collect) so that we can see that the intermediate result hasn't changed, even if a particular impl item has changed. So all in all I'm not quite sure whether to land this or not. =) It still seems like it has to be a win in some cases, but not with the test cases we have just now. I can try to gin up some test cases, but I'm not sure if they will be totally realistic. On the other hand, some of the early refactorings to the visitor trait seem worthwhile to me regardless. cc #36349 -- well, this is basically a fix for that issue, I guess r? @michaelwoerister NB: Based atop of @eddyb's PR #37402; don't land until that lands.
|
So... since #37660 landed, is this not fixed? :D |
|
It's basically fixed, yeah. But we can wait for #37712 |
|
#37712 has landed, closing. |
Currently there is only one dependency graph node for all items within a given
impl. This leads to false positives when detecting changes in methods, that is, changing one method makes the compiler consider the sibling methods to be changed too.This can be solved by giving each method its own dep-graph node.
The text was updated successfully, but these errors were encountered: