This commit adds an `ImplicitSelfKind` to the HIR and the MIR that keeps
track of whether a implicit self argument is immutable by-value, mutable
by-value, immutable reference or mutable reference so that the addition
of the `mut` keyword can be suggested for the immutable by-value case.
Fixes the hash test to recognize that MirValidated can change when changing
around labels, and add a new test that makes sure we're lowering loop statements
correctly.
I also added some comments explaining what is going on. In short, the
changes in question do not, in fact, affect the`TypeckTables` in any
semantic way. However, altering the order of lowering can cause it
appear to affect the `TypeckTables`: if we lower generics before the
body, then the `HirId` for things in the body will be affected. In
this case, we are now lowering the generics etc
*after* the body, so the hash no longer changes. This seems good.
update let-expressions hash test to use `except`
A part of #44924, this PR updated let-expressions test using `except`.
cc @michaelwoerister
r? @nikomatsakis
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
