-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
This looks pretty good. I think we also need to zero on moves ( |
@bors r+ (should be no conflict with other PR landing, though one hopes it doesn't bounce) |
📌 Commit 69b6f72 has been approved by |
🙀 |
@bors r=nikomatsakis |
📌 Commit 569b18f has been approved by |
⌛ Testing commit 569b18f with merge 831a453... |
💔 Test failed - auto-linux-64-nopt-t |
☔ The latest upstream changes (presumably #31282) made this pull request unmergeable. Please resolve the merge conflicts. |
I’m genuinely confused about the test failure here. |
Indeed, it's confusing. I pulled the branch locally and am doing a build, just to see what I see. |
@nagisa maybe rebase and we'll just give it the ol' bors retry? |
never mind, the error is quite reproducible if you configure with |
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.
@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.
@bors r+ |
📌 Commit d1a1239 has been approved by |
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)
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 ? |
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. |
Alright. My worry is code that uses Is it the plan to not enable MIR until it comes with proper drop flags on the stack and |
This uses the same kind of filling that non-MIR uses. We should revert this commit when pnkfelix gets stack-flag drop working. |
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)