| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Setup two tasks, one of which only processes the signatures, in order to
isolate the typeck entries for signatures from those for bodies.
Fixes #36078
Fixes #37720
|
|
This used to work with the rustc_clean attribute, but doesn't anymore
since my rebase; but I don't know enough about the type checking to find
out what's wrong. The dep graph looks like this:
ItemSignature(xxxx) -> CollectItem(xxxx)
CollectItem(xxxx) -> ItemSignature(xxxx)
ItemSignature(xxxx) -> TypeckItemBody(yyyy)
HirBody(xxxx) -> CollectItem(xxxx)
The cycle between CollectItem and ItemSignature looks wrong, and my
guess is the CollectItem -> ItemSignature edge shouldn't be there, but
I'm not sure how to prevent it.
|
|
|
|
|
|
|
|
|
|
Fixes #36168
|
|
ICH: Add regression tests for various kinds of loops.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
Ideally, callers should not be affected, but they currently are.
|
|
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 https://github.com/rust-lang/rust/pull/37402; don't land until that lands.
|
|
|
|
|
|
|
|
Also simplify some of the `ty::AssociatedItem` representation,
in particular by folding `has_value` into `hir::Defaultness`
|
|
Before, when we created an AssociatedItem for impl item X, we would read
the impl item itself. Now we instead load up the impl I that contains X
and read the data from the `ImplItemRef` for X; actually, we do it for
all impl items in I pre-emptively.
This kills the last source of edges between a method X and a call to a
method Y defined in the same impl.
Fixes #37121
|
|
|
|
|
|
ICH: Add test case for if- and if-let-expressions.
r? @nikomatsakis
|
|
|
|
|
|
ICH: Add tests for let- and match-expressions.
r? @nikomatsakis
|
|
|
|
|
|
|
|
Said code review and recommendations can be found here:
https://github.com/rust-lang/rust/pull/37610
|
|
|
|
ICH: Hash expression spans if their source location is captured for panics.
Since the location of some expressions is captured in error message constants, it has an influence on machine code and consequently we need to take them into account by the incr. comp. hash. This PR makes this happen for `+, -, *, /, %` and for array indexing -- let me know if I forgot anything.
In the future we might want to change the codegen strategy for those error messages, so that they are stored in a separate object file with a stable symbol name, so that only this object file has to be regenerated when source locations change. This strategy would also eliminate unnecessary duplications due to monomorphization, as @arielb1 has pointed out on IRC. I opened https://github.com/rust-lang/rust/issues/37512, so we don't forget about this.
r? @nikomatsakis
|
|
|
|
add more incremental reuse test cases
r? @michaelwoerister
This is basically a port of the "private method in impl". It works better when it's a top-level fn. =)
|
|
|
|
|
|
|
|
Currently doesn't work that well at all in terms of getting reuse
afterwards, see #37333. =)
|
|
|
|
add test case for changing private methods
The goal of this test case is to ensure we are getting the reuse we expect. This targets a particular change where we modify the body of a private inherent method defined on a struct, and looks at different ways we can use that struct.
It checks for when type-checking would be needed as well as the actual reuse achieved.
cc https://github.com/rust-lang/rust/issues/37121
r? @michaelwoerister
|
|
|
|
|
|
incr.comp.: Minor refactoring and update to struct ICH test case
r? @nikomatsakis
|
|
ICH: Enable some cases in trait definition hashing.
Enable some test cases originally written by @eulerdisk. The tests can be enabled now because @MathieuBordere has fixed the underlying problem in #36974.
r? @nikomatsakis
|
|
|
|
Fixes #37000.
|
|
Fixes #37001.
|
|
|
