Store fewer NodeIds in crate metadata. #43887
Conversation
|
I agree with the The |
|
Cannot build rustdoc. |
arielb1
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #43710) made this pull request unmergeable. Please resolve the merge conflicts. |
I'm fine with that if we can really switch it to However, it's also a question of whether |
|
@michaelwoerister The MIR borrow-checker will likely use a different representation, but I expect it to be months away. If |
|
I'm not convinced yet. This is not a straightforward refactoring. Making What I could also do is using |
michaelwoerister
force-pushed
the
node-id-be-gone
branch
2 times, most recently
from
761e9f8
to
8ecb35b
Compare
|
I think the plan with NLL (not MIR borrow-check) is to do away with |
|
Some thoughts: First off, I agree that as we move to NLL, this stuff will change and in particular My first reaction was similar to @eddyb -- that is, I would prefer to move away from Presumably we could rewrite Alternatively, I think the approach that @michaelwoerister wound up with might be ok "for a while", since we're planning on removing or reworking |
|
Moving to Using |
|
I'm surprised |
|
ping @michaelwoerister, just wanted to make sure this didn't fall off your radar! |
|
Well, my proposed solution to the |
It could show up in closure signatures, I believe. I'm not sure where else (hopefully not many places, if any!) |
|
@nikomatsakis I'm considering closures to be sharing |
carols10cents
added
S-waiting-on-review
|
@nikomatsakis @eddyb what are the next steps here? how should @michaelwoerister proceed? |
|
I still think |
|
☔ The latest upstream changes (presumably #43076) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I'm not sure how to reach consensus on this. I guess I feel somewhere in between @eddyb and @michaelwoerister -- I feel like it's probably true that it would work, but I don't know how best to be sure, or how to test if I am wrong other than weird ICEs. I'd prefer to unblock @michaelwoerister, so I am inclined in favor of the implementation that is actually working, but given that he is not around this week, maybe I will try to some time to read into the code a bit more to convince myself a bit more about it. |
|
I'll attempt the |
|
I think the only problem so far is error reporting for lifetimes which is a mess. I'll try to see what I can do about that. |
|
@michaelwoerister I was wondering if you had any tests for this change, to check them on top of #44171 - but I don't see any in this PR. |
|
@bors retry Looks like some kind of timeout... |
|
⌛ Testing commit 773736c with merge 90e3d4253f5148dac644a36798742c1b443a2b5d... |
|
💔 Test failed - status-travis |
|
@bors retry the macs are timing out again. |
|
⌛ Testing commit 773736c with merge de9d61169be4b587fc069de2adedb089bb6ae71a... |
|
💔 Test failed - status-travis |
|
⌛ Testing commit 773736c with merge f49707b9f4ecb7ba964db2c1509d696183500ea9... |
|
💔 Test failed - status-appveyor |
`check x86_64-pc-windows-gnu` failed 😒 |
Store fewer NodeIds in crate metadata. The first commit just replaces `NodeId` with `DefId` in `resolve_lifetime::Region`, so we don't run into problems when stable-hashing `TypeParameterDef` values from other crates. ~~The second commit is more interesting. It adds the `ReScopeAnon` variant to `ty::RegionKind`, which is semantically equivalent to `ReScope`. The only difference is that it does not contain a `CodeExtent` field. All `ReScope` occurrences are then replaced with `ReScopeAnon` upon metadata export. This way we don't end up with `NodeIds` from other crates in various things imported from metadata. `ReScopeAnon` can still be tested for equality.~~ This is fixed in a better way by @eddyb in #44171. r? @eddyb cc @rust-lang/compiler
|
💔 Test failed - status-travis |
|
@bors: retry
|
|
⌛ Testing commit 773736c with merge c132bd0de6fa65a07cb0a36ac538a99c97a12588... |
|
💔 Test failed - status-travis |
|
Closing in favor of #44364. |
…s2, r=nikomatsakis incr.comp.: Compute fingerprint for all query results. This PR enables query result fingerprinting in incremental mode. This is an essential piece of infrastructure for red/green tracking. We don't do anything with the fingerprints yet but merging the infrastructure should protect it from bit-rotting and will make it easier to start measuring its performance impact (and thus let us determine if we should switch to a faster hashing algorithm rather sooner than later). Note, this PR also includes the changes from rust-lang#43887 which I'm therefore closing. No need to re-review the first commit though. r? @nikomatsakis
…s2, r=nikomatsakis incr.comp.: Compute fingerprint for all query results. This PR enables query result fingerprinting in incremental mode. This is an essential piece of infrastructure for red/green tracking. We don't do anything with the fingerprints yet but merging the infrastructure should protect it from bit-rotting and will make it easier to start measuring its performance impact (and thus let us determine if we should switch to a faster hashing algorithm rather sooner than later). Note, this PR also includes the changes from rust-lang#43887 which I'm therefore closing. No need to re-review the first commit though. r? @nikomatsakis
The first commit just replaces
NodeIdwithDefIdinresolve_lifetime::Region, so we don't run into problems when stable-hashingTypeParameterDefvalues from other crates.The second commit is more interesting. It adds theThis is fixed in a better way by @eddyb in #44171.ReScopeAnonvariant toty::RegionKind, which is semantically equivalent toReScope. The only difference is that it does not contain aCodeExtentfield. AllReScopeoccurrences are then replaced withReScopeAnonupon metadata export. This way we don't end up withNodeIdsfrom other crates in various things imported from metadata.ReScopeAnoncan still be tested for equality.r? @eddyb
cc @rust-lang/compiler