incr.comp.: Verify stability of incr. comp. hashes and clean up various other things.
The main contribution of this PR is that it adds the `-Z incremental-verify-ich` functionality. Normally, when the red-green tracking system determines that a certain query result has not changed, it does not re-compute the incr. comp. hash (ICH) for that query result because that hash is already known. `-Z incremental-verify-ich` tells the compiler to re-hash the query result and compare the new hash against the cached hash. This is a rather thorough way of
- testing hashing implementation stability,
- finding missing `[input]` annotations on `DepNodes`, and
- finding missing read-edges,
since both a missed read and a missing `[input]` annotation can lead to something being marked as green instead of red and thus will have a different hash than it should have.
Case in point, implementing this verification logic and activating it for all `src/test/incremental` tests has revealed several such oversights, all of which are fixed in this PR.
r? @nikomatsakis
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
Now that we are visiting things in a different order during lowering,
adding parameters winds up affecting the HirIds assigned to thinks in
the method body, whereas it didn't before. We could fix this by
reordering the order in which we visit `generics` during lowering, but
this feels very fragile. Seems better to just let typeck tables be
dirty here.
Incremental compilation auto assert (with except)
cc @michaelwoerister
bors merged part 1, so this is a WIP of part 2 of #45009 -- auto asserting DepNodes depending on the type of node rustc_clean/dirty is attached to
Framework:
- [x] finish auto-detection for specified DepNodes
- [x] finish auto-detection for remaining DepNodes
Test Refactors:
- [x] consts.rs
- [x] enum_constructors.rs
- [x] extern_mods.rs
- [x] inherent_impls.rs
- [x] statics.rs
- [x] struct_constructors.rs
- ~~**BLOCKED** trait_defs.rs, see FIXME~~
- ~~**BLOCKED** trait_impls.rs~~
- [x] type_defs.rs
- [x] enum_defs.rs
This adds auto-assertion to `rustc_clean/dirty` and also implements
more comprehensive testing for
- src/test/incremental/hashes/enum_constructors.rs
- src/test/incremental/hashes/enum_defs.rs
- src/test/incremental/hashes/extern_mods.rs
- src/test/incremental/hashes/inherent_impls.rs
- src/test/incremental/hashes/statics.rs
- src/test/incremental/hashes/struct_constructors.rs
- src/test/incremental/hashes/type_defs.rs
trait_defs.rs and trait_impl.rs are blocked on a hard to triage
compiler ICE (at least hard for a newbie like me) having to do
with some DepNodes not getting computed for traits.
A FIXME has been added in the source to reflect this continued
work.
Initial support for `..=` syntax
#28237
This PR adds `..=` as a synonym for `...` in patterns and expressions.
Since `...` in expressions was never stable, we now issue a warning.
cc @durka
r? @aturon
Add ..= to the parser
Add ..= to libproc_macro
Add ..= to ICH
Highlight ..= in rustdoc
Update impl Debug for RangeInclusive to ..=
Replace `...` to `..=` in range docs
Make the dotdoteq warning point to the ...
Add warning for ... in expressions
Updated more tests to the ..= syntax
Updated even more tests to the ..= syntax
Updated the inclusive_range entry in unstable book
Instead of collecting all potential inputs to some metadata entry and
hashing those, we directly hash the values we are storing in metadata.
This is more accurate and doesn't suffer from quadratic blow-up when
many entries have the same dependencies.
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.
