-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Combine input and eval_always query types #59091
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