Skip to content
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

[WIP] Move drop elaboration before borrowck #107732

Closed
wants to merge 4 commits into from

Conversation

zeegomo
Copy link
Contributor

@zeegomo zeegomo commented Feb 6, 2023

Proof of concept to show what's needed to move drop elaboration before borrow checking. Ideally we could have it right after MIR build, but this tries to be as minimal as possible.

There are a few hacks, mostly around drop-elaboration code that does not pass borrowck / move analysis.

I plan to work on the remaining failing tests in the coming days

@rustbot
Copy link
Collaborator

rustbot commented Feb 6, 2023

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 6, 2023
@rustbot
Copy link
Collaborator

rustbot commented Feb 6, 2023

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rust-log-analyzer

This comment has been minimized.

@WaffleLapkin
Copy link
Member

r? compiler

@rustbot rustbot assigned davidtwco and unassigned WaffleLapkin Feb 7, 2023
@zeegomo
Copy link
Contributor Author

zeegomo commented Feb 7, 2023

My bad, I tested the last couple refactorings without a complete build, will fix it later today.

I'm kind of confused, can't reproduce the failure locally with x.py build/test/check even on a fresh clone

@rust-log-analyzer

This comment has been minimized.

POC to show what's needed to move drop elaboration before borrow
checking. Ideally we could have it right aftr MIR build, but this
tries to be as minimal as possible.

There are a few hacks, mostly around drop-elaboration code that
does not pass borrowck / move analysis.

I plan to work on the remaining failing tests in the near future.
@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Feb 9, 2023

☔ The latest upstream changes (presumably #107811) made this pull request unmergeable. Please resolve the merge conflicts.

@davidtwco
Copy link
Member

r? @cjgillot

@rustbot rustbot assigned cjgillot and unassigned davidtwco Feb 13, 2023
Only remove unreachable blocks after drop elaboration but
avoid merging blocks, as that sometimes confuses borrowck
precomputation of borrows_out_of_scope.
See issue rust-lang#80949 for more details.
@bjorn3
Copy link
Member

bjorn3 commented Feb 23, 2023

It looks like this will conflict with #106430. This PR removes dead unwinds before drop elaboration, but borrowck needs to know about these dead unwinds.

@zeegomo
Copy link
Contributor Author

zeegomo commented Feb 23, 2023

but borrowck needs to know about these dead unwinds.

Could you please elaborate on why?
I was under the impression that borrowck cared about the special False{Edge, Unwind} (which are untouched by both this and #106430) but not 'normal' unwinds more than any other dead block (which are already removed before borrowck by a few passes of SimplifyCfg)

@bjorn3
Copy link
Member

bjorn3 commented Feb 23, 2023

Borrowck cares about all jump and unwind edges. FalseEdge and FalseUnwind are used for when during mir building it is already known that the jump and unwind edges can't happen and there is nothing to attach those edges to otherwise. For example in case of an infinite loop. Drop elaboration would need to add FalseUnwind to preserve unwind edges for borrowck if it is moved before borrowck. As for why borrowck cares, see the doc comment on FalseUnwind:

A terminator for blocks that only take one path in reality, but where we reserve the right to unwind in borrowck, even if it won’t happen in practice.
[...]
The imaginary cleanup block link. This particular path will never be taken in practice, but in order to avoid fragility we want to always consider it in borrowck. We don’t want to accept programs which pass borrowck only when panic=abort or some assertions are disabled due to release vs. debug mode builds. This needs to be an Option because of the remove_noop_landing_pads and abort_unwinding_calls passes.

Drop elaboration sometimes add discriminant reads that access
a partially moved value.
This commits adds a new DesugaringKind::Drop mark to the span
used for elements added by drop elaboration, so that we can
selectively ignore only such discriminant reads.
@cjgillot cjgillot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 25, 2023
Drop elaboration introduces box_free calls which
are not always allowed by borrowck.
In particular, borrowck can't correlate the value
of drop flags to the initializations status of their
corresponding variable, so any box_free after a drop
flag read will present problems to the borrowck as
its arguments will be flagged as maybe uninitialized.
However, this is already what is happening with Drops
where borrowck trusts drop elaboration to do the right
thing, and we just extend this logic to box_free.
@Dylan-DPC Dylan-DPC marked this pull request as draft May 19, 2023 11:32
@Dylan-DPC
Copy link
Member

@zeegomo any updates on this?

@zeegomo
Copy link
Contributor Author

zeegomo commented May 22, 2023

Unfortunately I don't have the bandwidth at the moment to continue this work

@Dylan-DPC
Copy link
Member

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks

@Dylan-DPC Dylan-DPC closed this Oct 15, 2023
@Dylan-DPC Dylan-DPC added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants