In the JSInliner we shouldn't introduce JSConvertReceiver needlessly if
the input is already known to produce a receiver, i.e. if it's a
JSCreate or something like that.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2697513010
Cr-Commit-Position: refs/heads/master@{#43273}
Before this change, presubmit on upload/commit would miss checking status files when e.g. test files were deleted.
But the status file check in CI will enforce that all referenced test files exist.
NOTRY=true
Change-Id: I6069563a0a4e98406977dbce2ae44b299f7cd4b0
Reviewed-on: https://chromium-review.googlesource.com/443467
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43270}
The CodeStubAssembler::SubString method should not try to be defensive
about non-string inputs, but really enforce String receiver. Passing
a non-String input will result in crash in the %SubString runtime
function anyway.
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2700103002
Cr-Commit-Position: refs/heads/master@{#43267}
The new swarming archiving method requires isolate files to be copied to the build dir.
BUG=chromium:598990
NOTRY=true
TBR=tandrii@chromium.org,tansell@chromium.org,vogelheim@chromium.org
Change-Id: I87633725d9ce715684f761ce0c8d2691642c5389
Reviewed-on: https://chromium-review.googlesource.com/444644
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43266}
https://crrev.com/2500363002 updated FunctionTemplate::HasInstance to
follow the hidden prototype chain of a global proxy to the global
object. However, remote contexts don't have a global object to check;
instead, teach the instance check knows about the conventions of
global proxy setup and have it also check the constructor's prototype.
Similarly, also teach Object::FindInstanceInPrototypeChain about the
unusual conventions for remote contexts.
BUG=527190
Review-Url: https://codereview.chromium.org/2698683003
Cr-Commit-Position: refs/heads/master@{#43263}
For functions declared in source code, the .toString() representation
will be an excerpt of the source code.
* For functions declared with the "function" keyword, the excerpt
starts at the "function" or "async" keyword and ends at the final "}".
The previous behavior would start the excerpt at the "(" of the
parameter list, and prepend a canonical `"function " + name` or
similar, which would discard comments and formatting surrounding the
function's name. Anonymous functions declared as function expressions
no longer get the name "anonymous" in their toString representation.
* For methods, the excerpt starts at the "get", "set", "*" (for
generator methods), or property name, whichever comes first.
Previously, the toString representation for methods would use a
canonical prefix before the "(" of the parameter list. Note that any
"static" keyword is omitted.
* For arrow functions and class declarations, the excerpt is unchanged.
For functions created with the Function, GeneratorFunction, or
AsyncFunction constructors:
* The string separating the parameter text and body text is now
"\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
* At one point, newline normalization was required by the spec here,
but that was removed from the spec, and so this CL does not do it.
Included in this CL is a fix for CreateDynamicFunction parsing. ')'
and '`' characters in the parameter string are no longer disallowed,
and Function("a=function(", "}){") is no longer allowed.
BUG=v8:4958, v8:4230
Review-Url: https://codereview.chromium.org/2156303002
Cr-Commit-Position: refs/heads/master@{#43262}
Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.
After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.
Some highlights from the CL:
* Added methods to the CSA and InterpreterAssembler to efficiently store and
load Smis values and Smi interpreter registers on x64 without explicit
tagging/untagging.
* Created Variables for all of the interpreter-internal values that need to be
reloaded before bytecode dispatch at the end of an interpreter handler.
* The bytecode offset can be written out early in a handler by marking it
has having a call along it's critical path. By moving this early in a
handler, it becomes possible to use memory operands for pushes used to
marshall parameters when making calls.
Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
This changes most callers of ParseScopedStatement to call a new, simpler form
of ParseStatement, which takes only |labels| and |ok|. This allows us to remove
the |legacy| attribute from ParseScopedStatement.
The only remaining caller of ParseScopedStatement is ParseIfStatement.
This patch is a strict refactoring, and should change no behavior.
R=littledan@chromium.org
Review-Url: https://codereview.chromium.org/2699793002
Cr-Commit-Position: refs/heads/master@{#43259}
ES2017 forbids the sequence of tokens "let [" in in expression statements [1].
This CL makes ParserBase report those instances as SyntaxError. It also adds a
customised error message for that, because the standard "Unexpected token" is
not applicable: "let" itself is not forbidden in those context, only the
sequence of "let [".
[1] https://tc39.github.io/ecma262/#sec-expression-statement
BUG=v8:5686
Review-Url: https://codereview.chromium.org/2694003002
Cr-Commit-Position: refs/heads/master@{#43258}
This adds the possibility to specify a python script for post-processing stdout.
This also adds some system tests for testing the new feature.
NOTRY=true
Change-Id: I0383afb3e23513629508feeb639ed2dfce56b54a
Reviewed-on: https://chromium-review.googlesource.com/443449
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43257}
This improves the filter deciding whether a checkpoint needs to be
created. We now keep track of whether a node having an observable
side-effect has been created, allowing to elide checkpoint that are
provably effect-dominated by another checkpoint already.
By now the initial graphs contain an increasing amount of nodes marked
with {Operator::kNoWrite}, making this optimization worthwhile.
R=jarin@chromium.org
Change-Id: Ie7ffb67e1ab081ef7aa3017675afbe5f9e7601ab
Reviewed-on: https://chromium-review.googlesource.com/443466
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43256}
This upgrades to a precompiled plugin version including:
https://chromium.googlesource.com/v8/v8/+/4b0edcf7
BUG=v8:5970
TBR=clemensh@chromium.org,mstarzinger@chromium.org
Change-Id: I28ecdd568e4bc075533b3d14b7946a4a7ce5f9e0
Reviewed-on: https://chromium-review.googlesource.com/443648
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43255}
The default locale can be changed in some environments with environment
variables. These environment variables used to allow the system to get
into an invalid state, where the default locale was unsupported. This
patch detects that case and falls back to "und" as the default locale
if there is an Intl service which does not support the locale that ICU
reports as the default. It also has a slight cleanup of surrounding code.
I haven't gone through the work to set up an automated test, as triggering
the case requires setting environment variables, which our tests don't tend
to do, but I tested interactively as follows:
dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="tlh-FR" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"und"
d8> new Intl.NumberFormat().resolvedOptions().locale
"und"
d8>
dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="de" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat().resolvedOptions().locale
"de"
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"de"
d8>
BUG=v8:4216
Review-Url: https://codereview.chromium.org/2646593002
Cr-Commit-Position: refs/heads/master@{#43253}
We were looking at the unreachable flag or stack_depth of the target frame
instead of the current one in a couple of places (most notably BreakTo).
This change fixes these bugs and makes us pass the latest spec tests for
br_table validation. Also need to ensure that br_table targets have consistent
types, which is not implied if the stack is polymorphic.
R=titzer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2696813002
Cr-Commit-Position: refs/heads/master@{#43250}
The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).
This case is now rejected by the deserializer.
BUG=chromium:686511
Review-Url: https://codereview.chromium.org/2697023002
Cr-Commit-Position: refs/heads/master@{#43249}
One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.
The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.
For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.
BUG=chromium:689450
Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}
Map OOM breaks generated by inspector to DebugEvent.OOM.
This avoids generating unintentional DebugEvent.Break events.
Also be more future-proof in event categorization.
On a related note, this CL also fixes a DCHECK in
Runtime::GetFrameDetails.
The receiver needs to be grabbed from the inlined frame, not
the outer optimized frame. Optimized frames only provide the
receiver on a best-effort basis.
BUG=v8:5950
Review-Url: https://codereview.chromium.org/2696173002
Cr-Commit-Position: refs/heads/master@{#43244}
Reason for revert:
Please remove the file in status file too. Breaks presubmit:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/14754
Or lets call it post-submit :(
Original issue's description:
> This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.
>
> Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.
>
> BUG=v8:5946
> R=leszeks@chromium.org
>
> Review-Url: https://codereview.chromium.org/2684033007
> Cr-Commit-Position: refs/heads/master@{#43240}
> Committed: 4123a3dd79TBR=leszeks@chromium.org,mstarzinger@chromium.org,marja@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5946
Review-Url: https://codereview.chromium.org/2703553002
Cr-Commit-Position: refs/heads/master@{#43242}
Produce the same scopes / variables for parameters (part 3).
This CL fixes the ordering + variable types in PreParser when there are
simple parameters + a rest parameter. In that case, Parser declares
unnamed temporaries for the non-rest params, then the rest param, then
the named variables (which are not parameters) for the non-rest params.
BUG=v8:5516
R=vogelheim@chromium.org
Change-Id: I9b006595039c8002b0508d1d2a200aa9a0f3eae0
Reviewed-on: https://chromium-review.googlesource.com/443527
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43241}
ES2016 changed the default timezone of dates to be conditional on
whether a time is included. The semantics were a compromise approach
based on web compatibility feedback from V8, but until now, we have been
shipping ES5.1 default timezone semantics. This patch implements the
new semantics, following ChakraCore and SpiderMonkey (though JSC
implements V8's previous semantics).
BUG=chromium:589858
Review-Url: https://codereview.chromium.org/2648603002
Cr-Commit-Position: refs/heads/master@{#43239}
This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.
R=bmeurer@chromium.org
Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8
Reviewed-on: https://chromium-review.googlesource.com/443185
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43235}
@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.
This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.
BUG=v8:5361
Review-Url: https://codereview.chromium.org/2685183003
Cr-Commit-Position: refs/heads/master@{#43234}
The parser was finalizing the inner block scope, but not clearing the
inner block's scope pointer. This doesn't (yet) have any behavioral
difference, but makes it easier to make assumptions about the structure
of the AST vs the scope chain.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2696233003
Cr-Commit-Position: refs/heads/master@{#43233}
- Clear flags to avoid the quite expensive query for whether this page
is to be swept.
- Use a vector instead of a list as we always expect a small number of
pages to go through the pool and we want to avoid memory management on
this path.
BUG=
Change-Id: If3c0ad480b8e4f3ccf5a0ef43200c5269822245d
Reviewed-on: https://chromium-review.googlesource.com/443248
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43230}
This wraps float arrays with a proxy to make raw buffer use slow paths avoiding different NAN patterns.
This also mocks out large typed arrays when passing the lenth as third constructor parameter.
BUG=chromium:691287,chromium:690898
NOTRY=true
Change-Id: Ic4295b0d8690e5209aceeda9ed93efdd580194c0
Reviewed-on: https://chromium-review.googlesource.com/441624
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43229}
Some of these functions are invoked by BytecodeGenerator due to parser
desugarings, and moving the context indices cause
BytecodeExpectationsPrinter to render them as something
useful/meaningful.
BUG=
R=jgruber@chromium.org, adamk@chromium.org
Review-Url: https://codereview.chromium.org/2695323002
Cr-Commit-Position: refs/heads/master@{#43225}
When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.
the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/
BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org
Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}
