diff options
| author | Manish Goregaokar <manishsmail@gmail.com> | 2016-01-14 04:22:19 +0530 |
|---|---|---|
| committer | Manish Goregaokar <manishsmail@gmail.com> | 2016-01-14 11:04:41 +0530 |
| commit | 9036c82781c9666836b724c62f3a478505cdead7 (patch) | |
| tree | 0cd9472a47fb80777b6be3a9e80d8ade0732d6ae /src/rustllvm/RustWrapper.cpp | |
| parent | 3e248aa09ff211e76bb0a8ca53267c5a903c23ce (diff) | |
| parent | decc2867577c65682c6a73c89c550d34b5b270ad (diff) | |
| download | rust-9036c82781c9666836b724c62f3a478505cdead7.tar.gz rust-9036c82781c9666836b724c62f3a478505cdead7.zip | |
Rollup merge of #30823 - pnkfelix:put-back-alloca-zeroing-for-issue-30530, r=dotdash
Put back alloca zeroing for issues #29092, #30018, #30530; inject zeroing for #30822. ---- Background context: `fn alloca_zeroed` was removed in PR #22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's. ---- I first fixed #30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of #30530. While making the regression test for the latter, I discovered #30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant. I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action). ---- (*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value. Fix #29092 Fix #30018 Fix #30530 Fix #30822
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
