-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make expansions stable for incr. comp. #86676
Conversation
Some changes occurred in src/tools/rustfmt. |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 48374baa140a0358612b4c1be2f7d8716620519d with merge 10d3de9d420a0b3963c1d7182283d29ff22412d5... |
☀️ Try build successful - checks-actions |
Queued 10d3de9d420a0b3963c1d7182283d29ff22412d5 with parent 9cdb2d3, future comparison URL. |
Finished benchmarking try commit (10d3de9d420a0b3963c1d7182283d29ff22412d5): comparison url. Summary: This change led to significant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Error: Label perf-regression can only be set by Rust team members Please let |
(I'll get to this next weekend, most likely.) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Phew, I did a first pass over this PR just to understand what's going on, and it took a ~whole working day because the PR does a lot, it would be better to break it into parts if possible. |
The fundamental difference between hashes used for definitions and expansions right now is that in case of definitions we a hashing something that is "resistant to small changes" (a def path), but in case of expansions we are just accumulating the whole |
General comments:
I doubt that it's possible to extract some "pure refactoring" parts from this PR, because the whole PR is kind of a gradual refactoring, but if it's possible, then it would be great. |
Sorry for the lack of explanations.
I agree with this concern. I am trying to design an extension to #84373 which makes spans stable enough to resolve it.
I added a few commits and the current ones to avoid such back-and-forth. I could not find which functions you are referring to with
I extracted #87044 if it helps. |
|
One remaining question about duplicate tables - #86676 (comment). |
I have two reasons for keeping separate foreign tables:
If these are satisfactory, I will add them as comments. |
r=me after squashing all the review stuff into main commits. |
@bors r=petrochenkov |
📌 Commit b35ceee has been approved by |
☀️ Test successful - checks-actions |
This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions:
ExpnId
contains aCrateNum
and a crate-local id;ExpnHash <-> ExpnId
are setup;ExpnHash
.I tried to use as many
LocalExpnId
as I could in the resolver code, but I may have missed a few opportunities.All this will allow to use an
ExpnId
as a query key, and to force this query without recomputing caller queries. For instance, this will be used to implement #85999.r? @petrochenkov