Uh oh!
There was an error while loading. Please reload this page.
Make expansions stable for incr. comp. - #86676
Conversation
rust-highfive
commented
Jun 27, 2021
Some changes occurred in src/tools/rustfmt. |
cjgillot
commented
Jun 27, 2021
@bors try @rust-timer queue |
rust-timer
commented
Jun 27, 2021
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
Jun 27, 2021
⌛ Trying commit 48374baa140a0358612b4c1be2f7d8716620519d with merge 10d3de9d420a0b3963c1d7182283d29ff22412d5... |
bors
commented
Jun 27, 2021
☀️ Try build successful - checks-actions |
rust-timer
commented
Jun 27, 2021
Queued 10d3de9d420a0b3963c1d7182283d29ff22412d5 with parent 9cdb2d3, future comparison URL. |
rust-timer
commented
Jun 28, 2021
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 |
rustbot
commented
Jun 28, 2021
Error: Label perf-regression can only be set by Rust team members Please let |
petrochenkov
commented
Jul 4, 2021
(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.
petrochenkov
commented
Jul 9, 2021
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 |
petrochenkov
commented
Jul 9, 2021
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. |
cjgillot
commented
Jul 10, 2021
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. |
petrochenkov
commented
Jul 11, 2021
|
petrochenkov
commented
Jul 15, 2021
One remaining question about duplicate tables - #86676 (comment). |
cjgillot
commented
Jul 16, 2021
I have two reasons for keeping separate foreign tables:
If these are satisfactory, I will add them as comments. |
petrochenkov
commented
Jul 17, 2021
r=me after squashing all the review stuff into main commits. |
Uh oh!
There was an error while loading. Please reload this page.
cjgillot
commented
Jul 17, 2021
@bors r=petrochenkov |
bors
commented
Jul 17, 2021
📌 Commit b35ceee has been approved by |
bors
commented
Jul 17, 2021
bors
commented
Jul 17, 2021
☀️ Test successful - checks-actions |
This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions:
ExpnIdcontains aCrateNumand a crate-local id;ExpnHash <-> ExpnIdare setup;ExpnHash.I tried to use as many
LocalExpnIdas I could in the resolver code, but I may have missed a few opportunities.All this will allow to use an
ExpnIdas a query key, and to force this query without recomputing caller queries. For instance, this will be used to implement #85999.r? @petrochenkov