Replace zeroing-on-drop with filling-on-drop.

[pnkfelix]

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].

[rust-highfive]

r? @nrc

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

[pnkfelix]

r? @nikomatsakis

[huonw]

Could this be a wrapper around init_dropped?

[pnkfelix]

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...

[huonw]

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() }

[pnkfelix]

okay i will try that tomorrow morning

[pnkfelix]

ah it works like a charm, thanks huon, now I feel dumb. :)

[pnkfelix]

(@nrc notes that this PR is probably a good candidate for some run-pass-valgrind tests.)

[pnkfelix]

I may add a lint for enums using #[unsafe_no_drop_flag] because this really breaks those. (Is anyone using them?)

[eddyb]

@pnkfelix IME I don't recall ever seeing Drop implemented on enums, I wonder if we can quickly count them across the ecosystem.
The attribute itself applied on enums would be easy to grep for.

[nikomatsakis]

Oh, man, I totally missed this PR! Sorry for the delay @pnkfelix

[nikomatsakis]

r+ -- no real nits, just some questions

[pnkfelix]

@bors try

[bors]

⌛️ Trying commit fc87aa8 with merge 6efae5d...

[bors]

💔 Test failed - try-bsd

[pnkfelix]

@bors try

[bors]

⌛️ Trying commit 94392c8 with merge 969b386...

[bors]

💔 Test failed - try-mac

[Manishearth]

/Users/rustbuild/src/rust-buildbot/slave/try-mac/build/src/librustc_trans/trans/glue.rs:43:5: 43:33 error: unused import, #[deny(unused_imports)] on by default
/Users/rustbuild/src/rust-buildbot/slave/try-mac/build/src/librustc_trans/trans/glue.rs:43 use session::config::NoDebugInfo;
                                                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
make: *** [x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/stamp.rustc_trans] Error 101
make: *** Waiting for unfinished jobs....

[pnkfelix]

@bors try fd65e4f

[bors]

⌛️ Trying commit fd65e4f with merge a21e18f...

[bors]

💔 Test failed - try-mac

[bors]

⌛️ Trying commit e2cc8b1 with merge 961e035...

[bors]

☀️ Test successful - try-bsd, try-linux, try-mac, try-win-32, try-win-64

[pnkfelix]

@bors r=nikomatsakis e2cc8b1

[bors]

⌛️ Testing commit e2cc8b1 with merge b50bf4a...

[bors]

💔 Test failed - auto-mac-64-opt

[pnkfelix]

@bors r=nikomatsakis b68ca84

[bors]

⌛️ Testing commit b68ca84 with merge 74ab665...

[bors]

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

[pnkfelix]

@bors retry

[bors]

⌛️ Testing commit b68ca84 with merge be7f6ac...

[bors]

💔 Test failed - auto-win-32-nopt-t

[alexcrichton]

@bors: retry

On Fri, Mar 27, 2015 at 10:59 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-32-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-32-nopt-t/builds/3922

—
Reply to this email directly or view it on GitHub
#23535 (comment).

[bors]

⌛️ Testing commit b68ca84 with merge 46fa43d...

[pnkfelix]

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 unreachable block of the switch (which is then treated as undefined-behavior by LLVM).

[eddyb]

@pnkfelix but wouldn't there be a check for that value before the match on the discriminant?
Though I'm not aware of all the filling-drop details.

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. None) data that could drop and set the discriminant to it.

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?
Oh, it doesn't matter, because the data inside should be inert as well.

[pnkfelix]

@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 Drop also had 0 as a valid discriminant, and thus the compiler was freely inspecting the discriminant even on moved/dropped enum values.

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.

[eddyb]

@alexcrichton's ret void seems fine as long as it's limited to drop glue - I just checked #26025 and it isn't; might not be hard to add a parameter controlling that.