-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Clarify cross-crate dependency story #32015
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Save/load incremental compilation dep graph Contains the code to serialize/deserialize the dep graph to disk between executions. We also hash the item contents and compare to the new hashes. Also includes a unit test harness. There are definitely some known limitations, such as #32014 and #32015, but I am leaving those for follow-up work. Note that this PR builds on #32007, so the overlapping commits can be excluded from review. r? @michaelwoerister
Save/load incremental compilation dep graph Contains the code to serialize/deserialize the dep graph to disk between executions. We also hash the item contents and compare to the new hashes. Also includes a unit test harness. There are definitely some known limitations, such as #32014 and #32015, but I am leaving those for follow-up work. Note that this PR builds on #32007, so the overlapping commits can be excluded from review. r? @michaelwoerister
I think this is implemented (mostly via #32016) except for correctly handling access to inlined HIR.
|
I agree -- however, it seems like inlined HIR is going away. That is, once we transition to MIR trans, this point will no longer be an issue, right? |
Address ICEs running w/ incremental compilation and building glium Fixes for various ICEs I encountered trying to build glium with incremental compilation enabled. Building glium now works. Of the 4 ICEs, I have test cases for 3 of them -- I didn't isolate a test for the last commit and kind of want to go do other things -- most notably, figuring out why incremental isn't saving much *effort*. But if it seems worthwhile and I can come back and try to narrow down the problem. r? @michaelwoerister Fixes #34991 Fixes #32015
We're currently doing some wrong-ish things with respect to dep-graph tracking across crate boundaries. I think what I want to do is this:
DepNode::MetaData(DefId)
variant that plays a role likeHir
X
, we'll generate a read onMetaData(X)
For inlined items, I hope we will transition to MIR and not need to inline sooner or later, but in the meantime, I think we can basically translate reads to
Hir(X)
whereX
is an inlined def-id toMetaData(Y)
whereY
is the original def-id -- we may also just be able to ignore accesses to inlined def-ids, since we'll presumably add an appropriate edge from some other source.The text was updated successfully, but these errors were encountered: