This method uses in messages.js in GetSourceLine and GetPositionInLine. This methods uses in v8::Message API methods and there is no documentation about it.
Method looks obsolete.
One of the strange side effect is shown by attached issue.
BUG=chromium:468781
R=yangguo@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1022333004
Cr-Commit-Position: refs/heads/master@{#27374}
15.5.4.6 5.b requires each part to be converted using ToString(). This also needs to occur in the single argument fast-case.
BUG=v8:3981
R=arv@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1029103002
Cr-Commit-Position: refs/heads/master@{#27372}
This allows using %OptimizeFunctionOnNextCall and friends even when
Crankshaft is disabled. Note that this should only affect code paths
that are not relevant to performance. By now we have a single bailout
point in place within OptimizedCompileJob::CreateGraph that ensures
Crankshaft is only used when enabled and supported.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/999173007
Cr-Commit-Position: refs/heads/master@{#27367}
Port 34a1a76ddf
Original commit message:
A hydrogen code stub is not the best approach because it builds a frame
and doesn't have the technology to discard roots at tail call exits.
Platform-specific stubs provide much better performance at this point.
R=verwaest@chromium.org, mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1019003002
Cr-Commit-Position: refs/heads/master@{#27365}
port d4696c4841 (r27150)
original commit message:
This moves the decision whether to report a message or not to when
the pending exception is propagated instead of trying to preserve the
decision in a ThreadLocalTop field.
BUG=
Review URL: https://codereview.chromium.org/1028073002
Cr-Commit-Position: refs/heads/master@{#27360}
port f71e262683 (r27127)
original commit message:
Simplify pending message script handling.
This removes the separate tracking of the pending message script,
because that script is already stored in the message object and
duplicating it in the ThreadLocalTop makes it more brittle.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1028993003
Cr-Commit-Position: refs/heads/master@{#27358}
port 36e69a916f (r27115)
original commit message:
This reduces the size of the StackHandler by yet another word. We no
longer need to keep track of the frame pointer, as the stack walk will
be able to recalculate it.
BUG=
Review URL: https://codereview.chromium.org/1030563002
Cr-Commit-Position: refs/heads/master@{#27357}
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}
