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

[MIR] Some initial zeroing implementation work #31430

Merged
merged 6 commits into from
Mar 2, 2016

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Feb 5, 2016

Zeroing on-drop seems to work fine. Still thinking about the best way to approach zeroing on-move.

(based on top of the other drop PR; only the last 2 commits are relevant)

@nagisa
Copy link
Member Author

nagisa commented Feb 5, 2016

r? @nikomatsakis

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

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

@nikomatsakis
Copy link
Contributor

This looks pretty good. I think we also need to zero on moves (Use), and then we should be pretty much set.

@nikomatsakis
Copy link
Contributor

@bors r+ (should be no conflict with other PR landing, though one hopes it doesn't bounce)

@bors
Copy link
Contributor

bors commented Feb 5, 2016

📌 Commit 69b6f72 has been approved by nikomatsakis

@nagisa
Copy link
Member Author

nagisa commented Feb 6, 2016

@bors r=nikomatsakis eef0734

(rebased, since github didn’t quite figure it out I think?)

@bors
Copy link
Contributor

bors commented Feb 6, 2016

🙀 eef0734 is not a valid commit SHA. Please try again with 569b18f.

@nagisa
Copy link
Member Author

nagisa commented Feb 6, 2016

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Feb 6, 2016

📌 Commit 569b18f has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Feb 6, 2016

⌛ Testing commit 569b18f with merge 831a453...

@bors
Copy link
Contributor

bors commented Feb 7, 2016

💔 Test failed - auto-linux-64-nopt-t

@bors
Copy link
Contributor

bors commented Feb 9, 2016

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

@nagisa
Copy link
Member Author

nagisa commented Feb 9, 2016

I’m genuinely confused about the test failure here.

@nikomatsakis
Copy link
Contributor

Indeed, it's confusing. I pulled the branch locally and am doing a build, just to see what I see.

@nikomatsakis
Copy link
Contributor

@nagisa maybe rebase and we'll just give it the ol' bors retry?

@nikomatsakis
Copy link
Contributor

never mind, the error is quite reproducible if you configure with --disable-optimize-tests

Hopefully the author caught all the cases. For the mir_dynamic_drops_3 test case the ratio of
memsets to other instructions is 12%. On the other hand we actually do not double drop for at least
the test cases provided anymore in MIR.
@nagisa
Copy link
Member Author

nagisa commented Feb 24, 2016

@nikomatsakis re-r?

This has changed somewhat considerably since last time and now is a full-ish implementation.

In MIR we previously tried to match `let x in { exprs; let y in { exprs; }}` with our data
structures which is rather unwieldy, espeicially because it requires some sort of recursion or
stack to process, while, a flat list of statements is enough – lets only relinquish their lifetime
at the end of the block (i.e. end of the list).

Also fixes rust-lang#31853.
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Mar 1, 2016

📌 Commit d1a1239 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Mar 1, 2016

⌛ Testing commit d1a1239 with merge 339a409...

bors added a commit that referenced this pull request Mar 1, 2016
Zeroing on-drop seems to work fine. Still thinking about the best way to approach zeroing on-move.

(based on top of the other drop PR; only the last 2 commits are relevant)
@SimonSapin
Copy link
Contributor

I don’t understand the code changes but the PR title mentions zeroing rather than filling. Are we reverting https://internals.rust-lang.org/t/attention-hackers-filling-drop/1715 ?

@nagisa
Copy link
Member Author

nagisa commented Mar 7, 2016

This is using the same technique used by the current translator, so you could also call it filling (I personally see no distinction). This PR also affects MIR only (which is not used by default) and is a temporary solution until we make non-filling (stack flags) drops happen.

@SimonSapin
Copy link
Contributor

Alright. My worry is code that uses #[unsafe_no_drop_flag] and compares stuff to std::mem::POST_DROP_USIZE or std::mem::dropped(). I suppose it’ll be unaffected as long as MIR is not enabled by default.

Is it the plan to not enable MIR until it comes with proper drop flags on the stack and unsafe_no_drop_flag becomes unnecessary?

@arielb1
Copy link
Contributor

arielb1 commented Mar 8, 2016

@SimonSapin

This uses the same kind of filling that non-MIR uses. We should revert this commit when pnkfelix gets stack-flag drop working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants