Skip to content

Check for assignments between non-conflicting generator saved locals #73244

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 3 commits into from
Jun 24, 2020

Conversation

ecstatic-morse
Copy link
Contributor

@ecstatic-morse ecstatic-morse commented Jun 11, 2020

This is to prevent future changes to the generator transform from reintroducing the problem that caused #73137. Namely, a store between two generator saved locals whose storage does not conflict.

My ultimate goal is to introduce a modified version of #71956 that handles this case properly.

r? @tmandry

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 11, 2020
@ecstatic-morse ecstatic-morse changed the title Check for aliasing between non-conflicting generator saved locals Check for assignments between non-conflicting generator saved locals Jun 11, 2020
@ecstatic-morse
Copy link
Contributor Author

I ran this locally on the src/test/ui/{async-await,generator} tests with if opts.validate_mir part removed and everything passed.

Copy link
Member

@tmandry tmandry left a comment

Choose a reason for hiding this comment

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

Looks good! r=me after nits.

let lhs = match self.assigned_local {
Some(l) => l,
None => {
// We should be visiting all places used in the MIR.
Copy link
Member

Choose a reason for hiding this comment

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

I think the wording of this comment could be improved. The correctness of the code seems to hinge on the fact that we skip running f in check_assigned_place if the lhs is not saved. In those cases we don't visit all places used in the MIR.

Maybe the more generic "handling" is better?

Suggested change
// We should be visiting all places used in the MIR.
// We should be handling all place uses.

ecstatic-morse and others added 3 commits June 19, 2020 10:33
This is to prevent the miscompilation in rust-lang#73137 from reappearing.
Only runs with `-Zvalidate-mir`.
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
@ecstatic-morse ecstatic-morse force-pushed the validate-generator-mir branch from a6d5b33 to b2ec645 Compare June 19, 2020 17:35
self.check_assigned_place(*resume_arg, |this| this.visit_operand(value, location));
}

// FIXME: Does `asm!` have any aliasing requirements?
Copy link
Member

Choose a reason for hiding this comment

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

I don't think so. All inputs are completely moved to registers before running the inline asm and storing the outputs again.

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented Jun 22, 2020

@bors r=tmandry

Nits have been fixed. I'll handle the ASM FIXMEs separately.

@bors
Copy link
Collaborator

bors commented Jun 22, 2020

📌 Commit b2ec645 has been approved by tmandry

@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 Jun 22, 2020
@bors
Copy link
Collaborator

bors commented Jun 22, 2020

💡 This pull request was already approved, no need to approve it again.

  • There's another pull request that is currently being tested, blocking this pull request: Update cargo #73415

@bors
Copy link
Collaborator

bors commented Jun 22, 2020

📌 Commit b2ec645 has been approved by tmandry

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 23, 2020
…ir, r=tmandry

Check for assignments between non-conflicting generator saved locals

This is to prevent future changes to the generator transform from reintroducing the problem that caused rust-lang#73137. Namely, a store between two generator saved locals whose storage does not conflict.

My ultimate goal is to introduce a modified version of rust-lang#71956 that handles this case properly.

r? @tmandry
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 23, 2020
…ir, r=tmandry

Check for assignments between non-conflicting generator saved locals

This is to prevent future changes to the generator transform from reintroducing the problem that caused rust-lang#73137. Namely, a store between two generator saved locals whose storage does not conflict.

My ultimate goal is to introduce a modified version of rust-lang#71956 that handles this case properly.

r? @tmandry
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 23, 2020
…arth

Rollup of 11 pull requests

Successful merges:

 - rust-lang#72780 (Enforce doc alias check)
 - rust-lang#72876 (Mention that BTreeMap::new() doesn't allocate)
 - rust-lang#73244 (Check for assignments between non-conflicting generator saved locals)
 - rust-lang#73488 (code coverage foundation for hash and num_counters)
 - rust-lang#73523 (Fix -Z unpretty=everybody_loops)
 - rust-lang#73587 (Move remaining `NodeId` APIs from `Definitions` to `Resolver`)
 - rust-lang#73601 (Point at the call span when overflow occurs during monomorphization)
 - rust-lang#73613 (The const propagator cannot trace references.)
 - rust-lang#73614 (fix `intrinsics::needs_drop` docs)
 - rust-lang#73630 (Provide context on E0308 involving fn items)
 - rust-lang#73665 (rustc: Modernize wasm checks for atomics)

Failed merges:

r? @ghost
@@ -1315,3 +1341,134 @@ impl<'tcx> MirPass<'tcx> for StateTransform {
create_generator_resume_function(tcx, transform, source, body, can_return);
}
}

/// Looks for any assignments between locals (e.g., `_4 = _5`) that will both be converted to fields
Copy link
Member

@Aaron1011 Aaron1011 Jun 23, 2020

Choose a reason for hiding this comment

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

Why do we only need to validate assignments where the RHS is a direct usage of a local? Is there something else that prevents this kind of issue when an indirect usage is involved?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point.

Is MIR such as *p = *q or *p = q valid when p overlaps with q? p = *q is almost certainly invalid, and should be handled by this check. I'll check for all three versions in a subsequent PR.

@bors
Copy link
Collaborator

bors commented Jun 24, 2020

⌛ Testing commit b2ec645 with merge 0c04344...

@bors bors merged commit 781b589 into rust-lang:master Jun 24, 2020
@ecstatic-morse ecstatic-morse deleted the validate-generator-mir branch October 6, 2020 01:42
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants