wf: handle "livelock" checking before reaching WfPredicates::compute.#70170
wf: handle "livelock" checking before reaching WfPredicates::compute.#70170bors merged 2 commits intorust-lang:masterfrom
WfPredicates::compute.#70170Conversation
|
@bors try @rust-timer queue (there may be new noop |
|
Awaiting bors try build completion |
|
⌛ Trying commit 1b15eb9a35ef930ba373fc945ee84dcabededdff with merge 05f512090ead730e044e52571dba2da5ff8f9dcf... |
|
(I forgot to push some comment tweaks, hopefully it doesn't kill the try build) |
|
@rust-timer build 05f512090ead730e044e52571dba2da5ff8f9dcf |
|
Queued 05f512090ead730e044e52571dba2da5ff8f9dcf with parent f4c675c, future comparison URL. |
|
Finished benchmarking try commit 05f512090ead730e044e52571dba2da5ff8f9dcf, comparison URL. |
|
The worst regression, I guess I'll try to come up with a synthetic stress test that hits the worst case of this PR ( But still, 7.5% regression of |
|
☔ The latest upstream changes (presumably #70205) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Wait I forgot about this, this is technically a bugfix (before, if compute returned false here, those inference variables would be forgotten about).
So it might make sense that it's slower. Let me, uh, make a PR that only changes this, and check that for perf regressions.
EDIT: Actually, there's the entirety of #70168, predicate_obligations being the other user of .compute w/o checking the return value. I might be able to pinpoint where the extra obligations are coming from.
There was a problem hiding this comment.
This is it.
typeck_tables_of on clap-rs gets slightly faster (instead of being a significant regression), if I ignore upvar types that are ty::Infer(ty::TyVar(_)) and don't resolve.
But that's a WF hole, right? Do we just accept the regression?
There was a problem hiding this comment.
Sorry, I lost track of this PR. I agree that this is a bug-fix.
|
I added some fast paths, let's see if they improve anything (but also see #70170 (comment)): @bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit ef83aa34b11d92b10f53b514d04a5c2b475707d2 with merge bb0cbcbd0a0e408606210fa280cf86c90448764c... |
|
☀️ Try build successful - checks-azure |
|
Queued bb0cbcbd0a0e408606210fa280cf86c90448764c with parent 424c793, future comparison URL. |
|
Finished benchmarking try commit bb0cbcbd0a0e408606210fa280cf86c90448764c, comparison URL. |
|
Hehe, I think my second commit, I'm not surprised, there were a lot of macro-replicated integer literals in that code. |
|
I'm inclined to merge this PR @eddyb -- r=me on the code itself -- the clap-rs-debug perf regression seems small and I agree it's a bug fix, and there are some significant (albeit somewhat surprising?) improvements, too. I guess your explanation makes sense, though. |
|
Let's get some new numbers, post-rust-lang/rustc-perf#645: @bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit 05a872d with merge ad57f0a2528d29aca128300e3fa1b174a9eb497e... |
|
☀️ Try build successful - checks-azure |
|
Queued ad57f0a2528d29aca128300e3fa1b174a9eb497e with parent e94eaa6, future comparison URL. |
|
Finished benchmarking try commit ad57f0a2528d29aca128300e3fa1b174a9eb497e, comparison URL. |
|
@bors r=nikomatsakis rollup=never |
|
📌 Commit 05a872d has been approved by |
|
☀️ Test successful - checks-azure |
For
wf::obligations's "livelock" handling, this PR shouldn't cause any behavioral changes, as the check moved to it should be equivalent to the old one inWfPredicates::compute.However, it fixes #70168 by making other users of
WfPredicates::compute(that is,wf::predicate_obligationsandcompute's own upvar handling) correct forty::Infer, in that they now get aWellFormed(ty::Infer(_))obligation instead of silently ignoring the type.r? @nikomatsakis