-
Notifications
You must be signed in to change notification settings - Fork 14k
Implement ~const Destruct effect goal in the new solver
#132329
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
Conversation
|
☔ The latest upstream changes (presumably #132301) made this pull request unmergeable. Please resolve the merge conflicts. |
861399d to
242dd91
Compare
|
☔ The latest upstream changes (presumably #132479) made this pull request unmergeable. Please resolve the merge conflicts. |
e0730c9 to
313877d
Compare
|
r? @lcnr I know you don't typically review this const stuff, but it's touching the new solver so I know you may want to review this. also cc @RalfJung: are you familiar with the existing implementation of the |
|
Some changes occurred to the CTFE machinery cc @rust-lang/wg-const-eval |
| let cx = ecx.cx(); | ||
|
|
||
| let self_ty = goal.predicate.self_ty(); | ||
| let (tupled_inputs_and_output, def_id, args) = match self_ty.kind() { |
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.
We're not reusing the helper from structural_traits b/c we specifically want to extract a DefId here too.
I guess alternatively we could pass back an Option<DefId> from that helper and bail if it's None (i.e. a FnPtr), then do the const check afterwards.
|
|
||
| let self_ty = goal.predicate.self_ty(); | ||
|
|
||
| let const_conditions = match self_ty.kind() { |
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 could possibly uplift this to structural traits module too, I guess
I've seen it before but I am not very familiar with it, no... |
The Qualif API lets you do structural propagation of obligations but it also lets you "overwrite" that. So this sounds like just a plain bug in how the Qualif API is used. Probably because that code was written before |
There is no such qualif? I assume you mean |
8ceb8c2 to
6ab6f74
Compare
|
Firstly, the last commit is incomplete (needs a new feature gate). I just wanted to get it vibe-checked before fixing it up, since it's kinda tedious. |
| // I know it's not great to be creating a new const checker, but I'd | ||
| // rather use it so we can deduplicate the error emitting logic that | ||
| // it contains. | ||
| Checker::new(self.ccx).check_op_spanned_post( |
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.
Notably, I didn't want to recreate all of the logic having to do with conditional gating, so I create a new ConstChecker right here and immediately call check_op. That's kinda gross, I know; I guess I could alternatively abstract out the error reporting part? No strong opinion.
The point is that before this commit, I don't believe we were respecting feature gating or miri-unleashed properly with const_precise_live_drops enabled.
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.
Yeah, this entire separate pass is kind of a hack. This seems fine. Actually ideally we'd deduplicate this entire logic (first checking qualifs.needs_drop, then checking qualifs.needs_non_const_drop, then calling check_op_spanned) -- is that reasonably possible?
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.
Yeah, I can deduplicate the logic.
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.
Also, we don't need this _post function. I added it because I wanted to assert we were not registering any secondary diagnostics on this path, but we already delay a span bug if we do.
This comment has been minimized.
This comment has been minimized.
| // I know it's not great to be creating a new const checker, but I'd | ||
| // rather use it so we can deduplicate the error emitting logic that | ||
| // it contains. | ||
| Checker::new(self.ccx).check_op_spanned_post( |
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.
Yeah, this entire separate pass is kind of a hack. This seems fine. Actually ideally we'd deduplicate this entire logic (first checking qualifs.needs_drop, then checking qualifs.needs_non_const_drop, then calling check_op_spanned) -- is that reasonably possible?
I like the vibes! We'll only really see whether it behaves as expected once the tests are adjusted, but the code matches what I expect. I hope it makes sense to you as well? Definitely let me know if you think I am asking for something weird here. :) |
6ab6f74 to
6884fb4
Compare
…live_drops post-drop-elaboration check
2423525 to
6c92c33
Compare
6c92c33 to
69a38de
Compare
|
@bors r=lcnr |
|
💔 Test failed - checks-actions |
|
spurious? |
|
@bors retry this looks like some spurious miri crash ive seen in the past |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (743003b): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 2.1%, secondary -3.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -0.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 794.975s -> 795.253s (0.03%) |
This also fixed a subtle bug/limitation of the
NeedsConstDropcheck. Specifically, the "Qualif" API basically treats const drops as totally structural, even though dropping something that has an explicitDropimplementation cannot be structurally decomposed. For example:In this example, when checking if the
Conditional(())rvalue is const-drop, sinceConditionalhas a const destructor, we would previously recurse into the()value and determine it has nothing to drop, which means that it is considered to not need a const drop -- even though droppingConditional(())would mean evaluating the destructor which relies on thatT: const Foobound to hold!This could be fixed alternatively by banning any const conditions on
const Dropimpls, but that really sucks -- that means that basically no interesting const drop impls could be written. We have the capability to totally and intuitively support the right behavior, which I've implemented here.