Port
cf53fed972896bf23c037ce7ac9f8e1512463c62
Original commit message:
ArgumentsAdaptorStub for derived constructor (the one that needs
new.target) works in this way:
- If the constructor is invoked via the Construct stub, we know that
actual arguments always include new.target. ``arguments`` object
however should not include a new.target, therefore we remove it.
We achieve this by decrementing the argument count.
- If the constructor is invoked as a call, we do not care for a correct
``arguments`` array since the constructor will immediately throw on
entrance.
The bug is that the call could actually pass 0 actual arguments, but I
decrement unconditionally :(. The fix is to detect this case and avoid
decrementing. ``arguments`` is bogus, but it is ok as constructor
throws.
Long-term we should just remove mucking about with arguments for
new.target and just get it from the stack.
R=dslomov@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/
1125223002
Cr-Commit-Position: refs/heads/master@{#28269}
__ bind(&adaptor_frame);
__ LoadP(r4, MemOperand(r5, ArgumentsAdaptorFrameConstants::kLengthOffset));
if (has_new_target()) {
+ __ CmpSmiLiteral(r4, Smi::FromInt(0), r0);
+ Label skip_decrement;
+ __ beq(&skip_decrement);
// Subtract 1 from smi-tagged arguments count.
__ SubSmiLiteral(r4, r4, Smi::FromInt(1), r0);
+ __ bind(&skip_decrement);
}
__ StoreP(r4, MemOperand(sp, 0));
__ SmiToPtrArrayOffset(r6, r4);