-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add query to check for impossible predicates, use it to skip NoopMethodCall
and Inline
#95398
Add query to check for impossible predicates, use it to skip NoopMethodCall
and Inline
#95398
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #95436) made this pull request unmergeable. Please resolve the merge conflicts. |
825eafa
to
9436ebe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The query you created makes it seem like having impossible predicates is a property of an item. Should this check be done earlier, ie. at the beginning of typeck, in order to skip all the work of type checking and MIR building?
// parameters (e.g. `<T as Foo>::MyItem`). This can confuse | ||
// the normalization code (leading to cycle errors), since | ||
// it's usually never invoked in this way. | ||
query check_impossible_predicates_for_item(key: DefId) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you rename the query to make the bool
more explicit?
Something like item_has_impossible_predicates
?
// This branch will never be taken for any normal function. | ||
// However, it's possible to `#!feature(trivial_bounds)]` to write | ||
// a function with impossible to satisfy clauses, e.g.: | ||
// `fn foo() where String: Copy {}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This paragraph is outdated.
Yes, I agree that it's a property of the where clause on an item. However, they are allowed on the item with The current behavior is to typecheck the items as if these predicates are true. I think we should at least continue to typecheck the items given the false predicates -- though I wouldn't be opposed to skipping mir-build (or at least all of mir-opt) in the case that they have impossible predicates. This PR doesn't currently do that because I wanted to keep the affected compiler surface small, since it's the inliner that I have seen with the most ICEs due to calling |
☔ The latest upstream changes (presumably #85321) made this pull request unmergeable. Please resolve the merge conflicts. |
9436ebe
to
eb164bf
Compare
@rustbot author |
eb164bf
to
ed81aa6
Compare
@rustbot ready r? rust-lang/compiler |
let mut predicates = tcx.predicates_of(key.0).instantiate(tcx, key.1).predicates; | ||
predicates.retain(|predicate| !predicate.needs_subst()); | ||
let result = impossible_predicates(tcx, predicates); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's surprising to me that this doesn't just delegate to item_has_impossible_predicates_for_item
.
The behavior these two are slightly different; could they be merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to before, but I had some regressions.
I think I could try again if I'm smarter with some things though... I'll investigate this weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should land this in the meantime? If so, I think I'd like a FIXME added, but other than that, r=me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not ridiculously critical, so I'll play around with it this weekend and either r=you with a better description of why they're different, or unify these two.
ed81aa6
to
6fd51e7
Compare
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 41ad624 with merge c55a268fc101a6e678d0894680e56e83673f0993... |
☀️ Try build successful - checks-actions |
Queued c55a268fc101a6e678d0894680e56e83673f0993 with parent 18f314e, future comparison URL. |
Finished benchmarking commit (c55a268fc101a6e678d0894680e56e83673f0993): comparison url. Summary:
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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Footnotes |
Oof, that perf regression sucks. It's possibly because I'm elaborating the predicates always. Testing the previous implementation for perf regression in #96382. |
This was superseded by #96806 |
Fix a few cases where impossible founds can be found and can cause ICEs in codegen/linting.
Fixes #94999
Fixes #94680
Actually fixes #93008 this time