-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Combine input and eval_always query types #59091
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
Conversation
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors try |
⌛ Trying commit fcedb610a838198094138faf12791c65a8e72a90 with merge 9a5ed20247c2dec758878205c5208cf1916f93c7... |
As a possible alternative I also want to test the impact of replacing |
☀️ Try build successful - checks-travis |
@rust-timer build 9a5ed20247c2dec758878205c5208cf1916f93c7 |
Success: Queued 9a5ed20247c2dec758878205c5208cf1916f93c7 with parent 7486b9c, comparison URL. |
Finished benchmarking try commit 9a5ed20247c2dec758878205c5208cf1916f93c7 |
@rust-lang/compiler Any objections to this approach? We can turn these |
discussed at T-compiler meeting. @nikomatsakis may take a closer look , but the immediate reaction was "this sounds okay; it just needs a normal review process" |
I'll try to take a closer look at this this week. |
OK, so this looks good to me. The clean rebuild case is rather unrealistic (it models a rebuild after no source code and no dependencies have changed, something that is usually covered by cargo already). I'm a bit sad that the term @bors r+ |
📌 Commit 3f9c1cb1f33dca173c4ace458165dd0592182574 has been approved by |
Heads up, @rust-lang/wg-compiler-performance, this is expected to regress all |
☔ The latest upstream changes (presumably #59433) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors r=michaelwoerister |
📌 Commit 629e3a3 has been approved by |
Combine input and eval_always query types Hardcoding `Krate` as a dependency of `eval_always` queries doesn't really make sense if we want to use the query system before HIR lowering / hashing. Without that hardcoding they become pretty much identical to `input` queries, so I combined them to a single type. This will regress the `clean` incremental scenario, but that isn't terribly common. r? @michaelwoerister
Rollup of 10 pull requests Successful merges: - #58717 (Add FromStr impl for NonZero types) - #59091 (Combine input and eval_always query types) - #59216 (Type dependent defs wrappers) - #59318 (rustc: Update linker flavor inference from filename) - #59320 (rustc: Allow using `clang` for wasm32 targets) - #59363 (#59361 Moved rustc edition opt to short list) - #59371 (ffi: rename VaList::copy to VaList::with_copy) - #59398 (Add a way to track Rustfix UI test coverage) - #59408 (compiletest: make path normalization smarter) - #59429 (When moving out of a for loop head, suggest borrowing it in nll mode) Failed merges: r? @ghost
For the record, here are the perf results from the landing. |
Hardcoding
Krate
as a dependency ofeval_always
queries doesn't really make sense if we want to use the query system before HIR lowering / hashing. Without that hardcoding they become pretty much identical toinput
queries, so I combined them to a single type. This will regress theclean
incremental scenario, but that isn't terribly common.r? @michaelwoerister