-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Check const Drop
impls considering ~const
Bounds
#93028
Conversation
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.
On a first glance the changes LGTM.
Preferably we'd want to have some sort of wf check for impl const Drop
s that requires it to already satisfy the conditions for a structurally const Drop
, I'm not saying that it should be in this PR though.
I'll take a deeper look when I have time.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 33e5efb with merge 393a3fc1041abc8da9d58b1bded5f9319123be5a... |
☀️ Try build successful - checks-actions |
Queued 393a3fc1041abc8da9d58b1bded5f9319123be5a with parent 9ad5d82, future comparison URL. |
Finished benchmarking commit (393a3fc1041abc8da9d58b1bded5f9319123be5a): comparison url. Summary: This change led to large relevant regressions 😿 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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led 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 |
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 think I understand what is causing this regression: For user-defined types, you want to select bounds on impl const Drop
s of the types and check if all bounds are satisfied. Instead of nesting a lot of obligations and running the trait selection process many times, why not extract the components to check bounds for and do just that? For types that require the environment (parameter types) and types that are user-defined, collect them into a list and test them. For other trivial components don't even nest obligations for them.
compiler/rustc_middle/src/ty/util.rs
Outdated
| ty::Bound(..) | ||
| ty::Param(_) | ||
| ty::Placeholder(_) | ||
| ty::Never |
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 should be trivial to make Result<u8, !>: ~const Drop
.
I'm hesitant to structurally recurse on the type during candidate assembly (like the code was doing previously) because of normalization, and because other traits (e.g. Actually I think the regression might've gone away with the last commit I pushed, at least with local testing on the Also I'll put up a fix to make |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit ba87be0 with merge b27084a23c48a70efdfbe79d73610550c8326204... |
☀️ Try build successful - checks-actions |
Queued b27084a23c48a70efdfbe79d73610550c8326204 with parent e5e2b0b, future comparison URL. |
Finished benchmarking commit (b27084a23c48a70efdfbe79d73610550c8326204): comparison url. Summary: This change led to large relevant regressions 😿 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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led 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 |
I'll look into this, I guess. @rustbot author |
⌛ Testing commit b7e4433 with merge a63e6829dedc0100a777ce7851701f935e0bc337... |
💔 Test failed - checks-actions |
Bors seems to have failed for exactly no reason... let's try this again? Wonder if that delegate gives me @bors retry |
⌛ Testing commit b7e4433 with merge 9b1c49dfc9db1922001ed79cb726b59a96311103... |
💥 Test timed out |
@bors retry because installing awscli timed out (x86_64-msvc-1) |
I'll try this one more time before posting on zulip or something @bors retry spurious failure with no reason provided |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ef119d7): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
This PR adds logic to trait selection to account for
~const
bounds in customimpl const Drop
for types, elaborates theconst Drop
check inrustc_const_eval
to check those bounds, and steals some drop linting fixes from #92922, thanks @drmeepster.r? @fee1-dead @oli-obk (edit: guess I can't request review from two people, lol)
since each of you wrote and reviewed #88558, respectively.
Since the logic here is more complicated than what existed, it's possible that this is a perf regression. But it works correctly with tests, and that makes me happy.
Fixes #92881