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

Revert propagation of drop-live information from Polonius #125652

Merged
merged 3 commits into from
May 31, 2024

Conversation

amandasystems
Copy link
Contributor

#64749 introduced a flow of drop-use data from Polonius to LivenessResults::add_extra_drop_facts(), which makes LivenessResults agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.

@rustbot
Copy link
Collaborator

rustbot commented May 28, 2024

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 May 28, 2024
@amandasystems
Copy link
Contributor Author

Ok, apparently I did this on the wrong branch. Fixing it now!

@amandasystems amandasystems force-pushed the you-dropped-something branch from c8501e1 to 077a821 Compare May 28, 2024 11:07
@amandasystems
Copy link
Contributor Author

Done!

@oli-obk
Copy link
Contributor

oli-obk commented May 28, 2024

cc @matthewjasper

@amandasystems
Copy link
Contributor Author

Note the FIXME comment: I tried to figure out a way to neatly pass the fact data (which has finished baking and is safe to share) with LivenessResults but couldn't come up with anything more elegant.

This shunts all the complexity of siphoning off the drop-use facts
into `LivenessResults::add_extra_drop_facts()`, which may or may
not be a good approach.
@amandasystems
Copy link
Contributor Author

amandasystems commented May 28, 2024

I have a second version that's a lot cleaner, but which still somewhat more complicated. Either can be chosen really.

@oli-obk
Copy link
Contributor

oli-obk commented May 31, 2024

Yea I like the new version!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 31, 2024

📌 Commit 8066ebc has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 31, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 31, 2024
…g, r=oli-obk

Revert propagation of drop-live information from Polonius

rust-lang#64749 introduced a flow of drop-use data from Polonius to `LivenessResults::add_extra_drop_facts()`, which makes `LivenessResults` agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.
.borrowck_context
.all_facts
.as_ref()
.map(|facts| facts.var_dropped_at.clone())?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drive-by question: how big is this vec?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I wrote my master’s thesis drop-uses weren’t super common so I’d say small ish, but I’d like to remove this clone if possible.

Of course I had a dog walk idea how to do that just in time for it to get merged before I’d implemented it but I’ll look into it next time I need something to pass the time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should add that the clone happened in the original version too, except not as a clone but as a for each insert.

jieyouxu added a commit to jieyouxu/rust that referenced this pull request May 31, 2024
…g, r=oli-obk

Revert propagation of drop-live information from Polonius

rust-lang#64749 introduced a flow of drop-use data from Polonius to `LivenessResults::add_extra_drop_facts()`, which makes `LivenessResults` agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.
bors added a commit to rust-lang-ci/rust that referenced this pull request May 31, 2024
Rollup of 6 pull requests

Successful merges:

 - rust-lang#125652 (Revert propagation of drop-live information from Polonius)
 - rust-lang#125730 (Apply `x clippy --fix` and `x fmt` on Rustc)
 - rust-lang#125752 (run-make: enforce `#[must_use]` and arm command wrappers with drop bombs)
 - rust-lang#125756 (coverage: Optionally instrument the RHS of lazy logical operators)
 - rust-lang#125796 (Also InstSimplify `&raw*`)
 - rust-lang#125816 (Don't build the `rust-demangler` binary for coverage tests)

r? `@ghost`
`@rustbot` modify labels: rollup
jieyouxu added a commit to jieyouxu/rust that referenced this pull request May 31, 2024
…g, r=oli-obk

Revert propagation of drop-live information from Polonius

rust-lang#64749 introduced a flow of drop-use data from Polonius to `LivenessResults::add_extra_drop_facts()`, which makes `LivenessResults` agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.
bors added a commit to rust-lang-ci/rust that referenced this pull request May 31, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#125652 (Revert propagation of drop-live information from Polonius)
 - rust-lang#125730 (Apply `x clippy --fix` and `x fmt` on Rustc)
 - rust-lang#125756 (coverage: Optionally instrument the RHS of lazy logical operators)
 - rust-lang#125776 (Stop using `translate_args` in the new solver)
 - rust-lang#125796 (Also InstSimplify `&raw*`)
 - rust-lang#125807 (Also resolve the type of constants, even if we already turned it into an error constant)
 - rust-lang#125816 (Don't build the `rust-demangler` binary for coverage tests)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4b41136 into rust-lang:master May 31, 2024
6 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 31, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 31, 2024
Rollup merge of rust-lang#125652 - amandasystems:you-dropped-something, r=oli-obk

Revert propagation of drop-live information from Polonius

rust-lang#64749 introduced a flow of drop-use data from Polonius to `LivenessResults::add_extra_drop_facts()`, which makes `LivenessResults` agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.
amandasystems added a commit to amandasystems/rust that referenced this pull request Jun 5, 2024
The `use_polonius` flag is both redundant and confusing since every
function it's propagated to also checks if `all_facts` is `Some`,
the true test of whether to generate Polonius facts for Polonius
or for external consumers. This PR makes that path clearer by
simply doing away with the argument and handling the logic in
precisely two places: where facts are populated (check for `Some`),
and where `all_facts` are initialised. It also delays some statements
until after that check to avoid the miniscule performance penalty
of executing them when Polonius is disabled.

This also addresses @lqd's concern in rust-lang#125652 by reducing
the size of what is cloned out of Polonius facts to just the
facts being added, as opposed to the entire vector of potential
inputs, and added descriptive comments.

*Reviewer note*: the comments in [add_extra_drop_facts](https://github.com/rust-lang/rust/blob/85f90a461262f7ca37a6e629933d455fa9c3ee48/compiler/rustc_borrowck/src/type_check/liveness/trace.rs#L219) should be inspected by a reviewer,
in particular the one on L#259 in this PR, which should be trivial
for someone with the right background knowledge.

I also included some minor lints I found on the way there that I
couldn't help myself from addressing.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 24, 2024
…, r=nikomatsakis

Remove confusing `use_polonius` flag and do less cloning

The `use_polonius` flag is both redundant and confusing since every function it's propagated to also checks if `all_facts` is `Some`, the true test of whether to generate Polonius facts for Polonius or for external consumers. This PR makes that path clearer by simply doing away with the argument and handling the logic in precisely two places: where facts are populated (check for `Some`), and where `all_facts` are initialised. It also delays some statements until after that check to avoid the miniscule performance penalty of executing them when Polonius is disabled.

This also addresses `@lqd's` concern in rust-lang#125652 by reducing the size of what is cloned out of Polonius facts to just the facts being added, as opposed to the entire vector of potential inputs, and added descriptive comments.

*Reviewer note*: the comments in `add_extra_drop_facts` should be inspected by a reviewer, in particular the one on [L#259](https://github.com/rust-lang/rust/compare/master...amandasystems:you-dropped-this-again?expand=1#diff-aa727290e6670264df2face84f012897878e11a70e9c8b156543cfcd9619bac3R259) in this PR, which should be trivial for someone with the right background knowledge to address.

I also included some lints I found on the way there that I couldn't help myself from addressing.
tgross35 pushed a commit to tgross35/rust that referenced this pull request Jun 24, 2024
The `use_polonius` flag is both redundant and confusing since every
function it's propagated to also checks if `all_facts` is `Some`,
the true test of whether to generate Polonius facts for Polonius
or for external consumers. This PR makes that path clearer by
simply doing away with the argument and handling the logic in
precisely two places: where facts are populated (check for `Some`),
and where `all_facts` are initialised. It also delays some statements
until after that check to avoid the miniscule performance penalty
of executing them when Polonius is disabled.

This also addresses @lqd's concern in rust-lang#125652 by reducing
the size of what is cloned out of Polonius facts to just the
facts being added, as opposed to the entire vector of potential
inputs, and added descriptive comments.

*Reviewer note*: the comments in [add_extra_drop_facts](https://github.com/rust-lang/rust/blob/85f90a461262f7ca37a6e629933d455fa9c3ee48/compiler/rustc_borrowck/src/type_check/liveness/trace.rs#L219) should be inspected by a reviewer,
in particular the one on L#259 in this PR, which should be trivial
for someone with the right background knowledge.

I also included some minor lints I found on the way there that I
couldn't help myself from addressing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

5 participants