-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Replace zeroing-on-drop with filling-on-drop. #23535
Conversation
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
/// to non-zeroing drop. | ||
#[inline] | ||
#[unstable(feature = "filling_drop")] | ||
pub unsafe fn dropped<T>() -> T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be a wrapper around init_dropped
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to make it such a wrapper at one point in the history of the PR, but I got tired of trying to work out the staging issues involved...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh.
I guess this might work? (it might not too.)
#[cfg(stage0)]
pub unsafe fn dropped<T>() -> T { zeroed() }
#[cfg(not(stage0))]
pub unsafe fn dropped<T>() -> T { intrinsics::init_dropped() }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay i will try that tomorrow morning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah it works like a charm, thanks huon, now I feel dumb. :)
(@nrc notes that this PR is probably a good candidate for some run-pass-valgrind tests.) |
I may add a lint for enums using |
@pnkfelix IME I don't recall ever seeing |
Oh, man, I totally missed this PR! Sorry for the delay @pnkfelix |
r+ -- no real nits, just some questions |
@bors try |
⌛ Trying commit fc87aa8 with merge 6efae5d... |
💔 Test failed - try-bsd |
@bors try |
Replace zeroing-on-drop with filling-on-drop. This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future. Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files). See further discussion on the internals thread: http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11 [breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
💔 Test failed - try-mac |
|
94392c8
to
fd65e4f
Compare
Replace zeroing-on-drop with filling-on-drop. This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future. Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files). See further discussion on the internals thread: http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11 [breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
💔 Test failed - try-mac |
Refactored code so that the drop-flag values for initialized (`DTOR_NEEDED`) versus dropped (`DTOR_DONE`) are given explicit names. Add `mem::dropped()` (which with `DTOR_DONE == 0` is semantically the same as `mem::zeroed`, but the point is that it abstracts away from the particular choice of value for `DTOR_DONE`). Filling-drop needs to use something other than `ptr::read_and_zero`, so I added such a function: `ptr::read_and_drop`. But, libraries should not use it if they can otherwise avoid it. Fixes to tests to accommodate filling-drop.
…ile-fail tests. (I.e. the idea being, lets catch errors in these basic constructs sometime *before* we start doing the doc tests.)
☀️ Test successful - try-bsd, try-linux, try-mac, try-win-32, try-win-64 |
⌛ Testing commit e2cc8b1 with merge b50bf4a... |
💔 Test failed - auto-mac-64-opt |
⌛ Testing commit b68ca84 with merge 74ab665... |
💔 Test failed - auto-win-64-nopt-t |
@bors retry |
⌛ Testing commit b68ca84 with merge be7f6ac... |
💔 Test failed - auto-win-32-nopt-t |
@bors: retry On Fri, Mar 27, 2015 at 10:59 AM, bors notifications@github.com wrote:
|
Replace zeroing-on-drop with filling-on-drop. This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future. Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files). See further discussion on the internals thread: http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11 [breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
⌛ Testing commit b68ca84 with merge 46fa43d... |
Note: #26025 points out a potential bug injected by filling-drop; namely, there is a switch on the discriminant of an enum, which will now be set to a value outside the range of typical discriminants, and ends up jumping into an |
@pnkfelix but wouldn't there be a check for that value before the match on the discriminant? When I suggested the "poke as little to disable all possible dtors" interim solution, enum variants were the interesting case, because you could search for a variant with little (or no, e.g. Is that viable at all here? Or since this is a temporary measure, after all, maybe just add a case for the discriminant being filled with the value - but what if it's a valid discriminant for that enum? |
@eddyb we might need to add such a check-before-switch if filling-drop stays as it is today. But historically, as I understand it from what niko tells me, we were relying on the fact that every enum that could implement I don't know how viable it would be to attempt to fill with a "valid" enum variant. It seems sort of sketchy to me; it would require the filling code to be more aware of structural layout than it is today... I'd prefer to invest effort in finishing nonzeroing drop. |
@alexcrichton's |
Replace zeroing-on-drop with filling-on-drop.
This is meant to set the stage for removing all zeroing and filling (on drop) in the future.
Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files).
See further discussion on the internals thread:
http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11
[breaking-change] especially for structs / enums using
#[unsafe_no_drop_flag]
.