port 8d946b9c3f (r27106).
original commit message:
[es6] Throw TypeError for computed static prototype property name
The prototype of a class constructor function is read only. When we set
computed property names we were ignoring this and we were overriding the
property.
Since the prototype is the only possible own read only property on the
constructor function object we special case this so we do not have to
check this for every property in the class literal.
BUG=
Review URL: https://codereview.chromium.org/1028983002
Cr-Commit-Position: refs/heads/master@{#27356}
We were using ToObject in a lot of places where the common case is that
we already have an object. By changing to TO_OBJECT_INLINE we don't
have to go through 5 different if statements before falling through.
We were also calling ToObject too many times in DefineObjectProperty
where we already know that obj is an object.
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/1019413002
Cr-Commit-Position: refs/heads/master@{#27355}
The final spec for Object.getPrototypeOf calls ToObject on the
parameter, which means that it should only throw for null and
undefined. For other non object values the prototype of the wrapper
should be used.
BUG=v8:3964
LOG=N
R=adamk, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1014813003
Cr-Commit-Position: refs/heads/master@{#27354}
port e0aa8ebf93 (r27103).
original commit message:
This reduces the size of the StackHandler by one word. We no longer
need to keep track of the code object, as the stack walk finds it.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1022403002
Cr-Commit-Position: refs/heads/master@{#27353}
port 1382879f29 (r27016).
oringinal commit message:
[turbofan] Implement throwing exceptions into TurboFan code.
This extends the stack unwinding logic to respect optimized frames
and perform a lookup in the handler table to find handlers. It also
contains fixes to the API call stubs to allow a stack walk while
promoting scheduled exceptions.
BUG=
Review URL: https://codereview.chromium.org/1023943002
Cr-Commit-Position: refs/heads/master@{#27342}
port 2ecdf736cf (r27014).
original commit message:
Fix exception for assignment to uninitialised const.
BUG=
Review URL: https://codereview.chromium.org/1028533002
Cr-Commit-Position: refs/heads/master@{#27332}
To ensure termination, we need to be sure that once we start weakening
a node, we keep weakening that node in subsequent re-typings. Until now,
we were guessing that we previously weakened from the type. This
change introduces a set of nodes that have already be weakened, so
that we have a reliable way to detect previous weakening.
BUG=chromium:468799
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1019883002
Cr-Commit-Position: refs/heads/master@{#27331}
Port d21fd15467
Known issue: the mjsunit/harmony/reflect-construct test fails, it will be addressed in a follow-up CL.
BUG=
Review URL: https://codereview.chromium.org/1021863002
Cr-Commit-Position: refs/heads/master@{#27326}
The problem manifests itself when parsing manages to return something
meaningful in the presence of a stack overflow. This happens because
calling ParserBase::Next() will still return one valid token on stack
overflow, before starting to return invalid tokens.
Take the following input as example:
a.map(v => v + 1);
| |
already next token
parsed (which will be an invalid token
(identifier) because of a stack overflow)
The "v" may have been already parsed into a VariableProxy, then if a
stack overflow occurs, next token will be an invalid token (instead
of Token::ARROW), but the parser will return the VariableProxy.
This always happens when lazy-parsing arrow functions, so the position
in the input stream where the the arrow function code ends is known.
This fix adds a check that ensures that parsing ended at the end
position of the arrow function.
BUG=465671
LOG=N
Review URL: https://codereview.chromium.org/1023483003
Cr-Commit-Position: refs/heads/master@{#27325}
With this change, we remember the types of frame state inputs (in a new
operator, called TypedStateValues). Instead of inferring the value types
when building translations, we used the recorded types.
The original approach was not reliable because the passes after
simplified lowering can change node types, and this in turn confuses
the translation builder.
BUG=chromium:468727
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1015423002
Cr-Commit-Position: refs/heads/master@{#27310}
The CallInterfaceDescriptor already provides information about the
expected representation of parameters, so we can use that instead of
hardcoding tagged representation for all parameters.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1019293002
Cr-Commit-Position: refs/heads/master@{#27308}
