ES2015 generally bans FunctionDeclarations in positions which expect a Statement,
as opposed to a StatementListItem, such as a FunctionDeclaration which constitutes
the body of a for loop. However, Annex B 3.2 and 3.4 make exceptions for labeled
function declarations and function declarations as the body of an if statement in
sloppy mode, in the latter case specifying that the semantics are as if the
function declaration occurred in a block. Chrome has historically permitted
further extensions, for the body of any flow control construct.
This patch addresses both the syntactic and semantic mismatches between V8 and
the spec. For the semantic mismatch, function declarations as the body of if
statements change from unconditionally hoisting in certain cases to acquiring
the sloppy mode function in block semantics (based on Annex B 3.3). For the
extra syntax permitted, this patch adds a flag,
--harmony-restrictive-declarations, which excludes disallowed function declaration
cases. A new UseCounter, LegacyFunctionDeclaration, is added to count how often
function declarations occur as the body of other constructs in sloppy mode. With
this patch, the code generally follows the form of the specification with respect
to parsing FunctionDeclarations, rather than allowing them in arbitrary Statement
positions, and makes it more clear where our extensions occur.
BUG=v8:4647
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1757543003
Cr-Commit-Position: refs/heads/master@{#34470}
CallSite depends on using the function name to get ahold of the property
name from which an exception was thrown. This fix properly handles the
ES2015 names for getters and setters. The new tests pass both with
--harmony-function-name off and on.
BUG=v8:3699
LOG=n
Review URL: https://codereview.chromium.org/1751403004
Cr-Commit-Position: refs/heads/master@{#34469}
We cannot optimize away ToNumber conversions based on the Type that we
see in Crankshaft, as this might be the (unchecked or even pretruncated)
lower bound. We can only use the HType, which is based on the definition.
R=jkummerow@chromium.org
BUG=chromium:590989
LOG=n
Review URL: https://codereview.chromium.org/1757013002
Cr-Commit-Position: refs/heads/master@{#34445}
The function literal consists of a list of statements. Each statement
is associated with a statement position including break location. The
only exception to this rule is when the function immediately throws if
scope resolution found an illegal redeclaration. Make sure that we add a
break location for this case as well. The debugger relies on this.
R=bmeurer@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1759603002
Cr-Commit-Position: refs/heads/master@{#34422}
Adds the translation from optimized frame to bytecode offset
in FrameSummary. For interpreter, the bailout id represents the bytecode
array offset. So we can directly use the bailout id as the code offset
in the FrameSummary. Also updates mjsunit.status with more information
about failing tests.
BUG=v8:4280, v8:4689
LOG=N
Review URL: https://codereview.chromium.org/1740753002
Cr-Commit-Position: refs/heads/master@{#34393}
We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.
With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.
Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
position of the return statement.
- right before the actual return, there is another break location. The
source position points to the end of the function.
R=rmcilroy@chromium.org, vogelheim@chromium.orgTBR=rossberg@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1744123003
Cr-Commit-Position: refs/heads/master@{#34388}
ArrayIteratorPrototype must not provide Symbol.iterator.
R=rossberg
BUG=
Review URL: https://codereview.chromium.org/1749093002
Cr-Commit-Position: refs/heads/master@{#34386}
The for-of-finalization CL incorrectly removed the input argument from
BuildIteratorClose. I'm reverting this, adding a regression test, and fixing an
existing test that was wrong.
BUG=
R=rossberg
Review URL: https://codereview.chromium.org/1750543002
Cr-Commit-Position: refs/heads/master@{#34384}
The code used to [[Get]] the first element twice instead of once, which can be
observed (one of the kangax tests does so).
R=rossberg
BUG=
Review URL: https://codereview.chromium.org/1747933002
Cr-Commit-Position: refs/heads/master@{#34383}
The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.
Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.
R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n
Review URL: https://codereview.chromium.org/1738153002
Cr-Commit-Position: refs/heads/master@{#34335}
The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).
This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y
Review URL: https://codereview.chromium.org/1740123002
Cr-Commit-Position: refs/heads/master@{#34322}
The %TailCall runtime entry and the %_TailCall intrinsic is not used,
and will never be used (because %TailCall doesn't actually do a tail
call). We will soon have proper ES6 tail calls, which are correct and
properly tested.
The %Apply runtime entry is basically a super-slow, less correct version
of Reflect.apply, so we can as well just use Reflect.apply, which is
exposed to builtins via %reflect_apply.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/1739233002
Cr-Commit-Position: refs/heads/master@{#34317}
The %_Call intrinsic (if supported by the compiler) is lowered directly
to the Call builtin and thus throws a TypeError if the target is not
callable. The %Call runtime function also eventually calls into the Call
builtin, but had an early abort if the target is not a JSReceiver, which
is unnecessary and leads to various test failures for Ignition.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1727833006
Cr-Commit-Position: refs/heads/master@{#34316}
The treatment of different undetectable objects was inconsistent after
the latest changes to the undetectable bit in the maps. Given two
different undetectable JSObjects a and b, a monomorphic CompareIC would
say false for a == b, while the rest of the system (including the
generic case for the CompareIC) would say true.
The fix is rather straight-forward: We just go generic on a CompareIC
once we see an undetectable JSObject.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1735863004
Cr-Commit-Position: refs/heads/master@{#34315}
This patch moves iterator finalization (calling .return() when a
for-of loop exits early) to shipping. The only part of this feature
which is currently known to be missing is destructuring--.return()
should be also be called when destructuring with an array which
does not end in a rest pattern, but it currently does not. The rest
of this feature, including calling .return() from certain builtins,
is implemented.
R=adamk
BUG=v8:3566
LOG=Y
Review URL: https://codereview.chromium.org/1738463003
Cr-Commit-Position: refs/heads/master@{#34307}
By now the deprecation of strong mode is far enough along that the
support present in the interpreter matches the support in the other
compilers. Special expectations aren't needed anymore.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1738653003
Cr-Commit-Position: refs/heads/master@{#34293}
Handles stack overflow in interpreter.
1. When visiting function literal, if the shared function
info cannot be found we should return a stack overflow.
2. When visiting the ast graph, if stack overflow happens
then all the ast nodes are not visited, so we need to have
appropriate handling in the AccumulatorResultScope and
RegisterResultScope.
3. MakeBytecode should not return a suceess unconditionally.
If there is a stack overflow, it should return false, so
RangeError can be thrown.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1721983005
Cr-Commit-Position: refs/heads/master@{#34282}
When there is no receiver object, plain function calls are a few
percent faster than %_Call().
This patch also fixes the HAS_INDEX macro used in a bunch of
Array.prototype functions to properly check for elements inherited
from prototypes.
Review URL: https://codereview.chromium.org/1706213002
Cr-Commit-Position: refs/heads/master@{#34269}
There was a bug in for-of loops without newly declared variables: If,
in performing the assignment, an exception were thrown, then
IteratorClose would not be called. The problem was that the assignment
is done as part of assign_each, which happens before the loop is put
back in the state which is recognized to be breaking/throwing/returning
early.
This patch modifies the for-of desugaring by setting the loop state
before, rather than after, evaluating the assign_each portion, which is
responsible for evaluating the assignment in for-of loops which do not
have a declaration.
This patch, together with https://codereview.chromium.org/1728973002 ,
allow all test262 iterator return-related tests to pass.
R=rossberg
BUG=v8:4776
LOG=Y
Review URL: https://codereview.chromium.org/1731773003
Cr-Commit-Position: refs/heads/master@{#34262}
In the for-of desugaring, IteratorClose is a subtle thing to get right.
When return exists, the logic for which exception to throw is as follows:
1. Get the 'return' property and property any exception that might come from
the property read
2. Call return, not yet propagating an exception if it's thrown.
3. If we are closing the iterator due to an exception, propagate that error.
4. If return threw, propagate that error.
5. Check if return's return value was not an object, and throw if so
Previously, we were effectively doing step 5 even if an exception "had already
been thrown" by step 3. Because this took place in a finally block, the exception
"won the race" and was the one propagated to the user. The fix is a simple change
to the desugaring to do step 5 only if step 3 didn't happen.
R=rossberg
BUG=v8:4775
LOG=Y
Review URL: https://codereview.chromium.org/1728973002
Cr-Commit-Position: refs/heads/master@{#34261}
This fixes a corner case that triggered an assert in full-codegens
operand stack depth tracking. We stop pushing operands if we overflow
the C-stack while iterating the AST. This makes the tracking go out of
sync before we fully returned from the tree traversal, at which point
the thrown RangeError will abort compilation.
R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-589472
BUG=chromium:589472
LOG=n
Review URL: https://codereview.chromium.org/1732903002
Cr-Commit-Position: refs/heads/master@{#34255}
Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code related to the type feedback vector into the builtin.
Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680
Review URL: https://codereview.chromium.org/1731253003
Cr-Commit-Position: refs/heads/master@{#34252}
There was an eval inside the array_natives_test() which prevented
Crankshaft, even tho it's unrelated, and so we always went to TurboFan
now, which both decreased test coverage and increased time for stress
opt runs.
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/1725383002
Cr-Commit-Position: refs/heads/master@{#34248}
This implements proper handling of local control flow (i.e. break and
continue) that spans the boundary of a do-expression. We can no longer
determine the number of operands to be dropped from the nesting of
statements alone, instead we use the new precise operand stack depth
tracking.
R=jarin@chromium.org
TEST=mjsunit/harmony/do-expressions-control
BUG=v8:4488
LOG=n
Review URL: https://codereview.chromium.org/1724753002
Cr-Commit-Position: refs/heads/master@{#34246}
Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.
Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.
MIPS port contributed by balazs.kilvady.
BUG=v8:4280, v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1688283003
Cr-Commit-Position: refs/heads/master@{#34244}
