Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1584243002:
Don't pre-initialise block contexts with holes (Closed)
DescriptionDon't pre-initialise block contexts with holes
Respective declarations will explicitly initialise slots
with the hole anyway, so this always was unnecessary.
With varblocks it even became wrong, because block contexts
may now host var bindings, which want undefined.
Fixes the hole leaking when accessing an unitialised,
block-context-allocated var.
R=neis@chromium.org
BUG=571149
LOG=N
Committed: https://crrev.com/92e6f7a315355bd61cc85d78448e592ab5e125c8
Cr-Commit-Position: refs/heads/master@{#33309}
Patch Set 1 #Patch Set 2 : Adapt Turbofan #
Messages
Total messages: 26 (12 generated)
On 2016/01/14 15:57:37, rossberg wrote: Does this possibly have an impact on context-allocated `let` variables?
lgtm
On 2016/01/14 15:59:36, caitp wrote: > On 2016/01/14 15:57:37, rossberg wrote: > > Does this possibly have an impact on context-allocated `let` variables? after reading the description, I guess not :>
The CQ bit was checked by rossberg@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1584243002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1584243002/1
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: v8_presubmit on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/9766)
Description was changed from ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 ========== to ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 LOG=N ==========
The CQ bit was checked by rossberg@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1584243002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1584243002/1
The CQ bit was unchecked by rossberg@chromium.org
The CQ bit was checked by rossberg@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from neis@chromium.org Link to the patchset: https://codereview.chromium.org/1584243002/#ps20001 (title: "Adapt Turbofan")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1584243002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1584243002/20001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: v8_presubmit on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/9771)
rossberg@chromium.org changed reviewers: + mstarzinger@chromium.org
Now needs LGTM from compiler owner. Michi?
LGTM on "compiler", nice catch!
The CQ bit was checked by rossberg@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1584243002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1584243002/20001
Message was sent while issue was closed.
Description was changed from ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 LOG=N ========== to ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 LOG=N ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Description was changed from ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 LOG=N ========== to ========== Don't pre-initialise block contexts with holes Respective declarations will explicitly initialise slots with the hole anyway, so this always was unnecessary. With varblocks it even became wrong, because block contexts may now host var bindings, which want undefined. Fixes the hole leaking when accessing an unitialised, block-context-allocated var. R=neis@chromium.org BUG=571149 LOG=N Committed: https://crrev.com/92e6f7a315355bd61cc85d78448e592ab5e125c8 Cr-Commit-Position: refs/heads/master@{#33309} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/92e6f7a315355bd61cc85d78448e592ab5e125c8 Cr-Commit-Position: refs/heads/master@{#33309} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
