Formal parameters of an arrow function are parsed even if the function
itself is preparsed. It is because we don't know if it is an arrow
function parameter list or just comma separated expression list.
When we parse:
(a, b = (function c() { return a; })())
call to function c may be just part of an assignment in an expression
list, but if it's followed by:
=> { return b; }
It is an arrow function and the call to c is a default parameter.
Before we see the arrow we might have already created a parse task
to parse function c.
BUG=v8:6093
Change-Id: I59a59acfdbbfd808dab1518060748be2addcd54a
Reviewed-on: https://chromium-review.googlesource.com/493347
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45132}
Instead of explicitly instantiating six copies of each function for
zero to five arguments, define them as variadic template.
This avoids the arbitrary limit to five arguments, and avoids lots of
code duplication.
Drive-by fix: [iwyu] Add missing include.
R=mstarzinger@chromium.org
Change-Id: Id7edde3611ddfade16c7afbbf4b9000cedd76468
Reviewed-on: https://chromium-review.googlesource.com/496247
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45130}
Reason for revert:
box2d failures on buildbot
Original issue's description:
> [heap] Reland "Make non-atomic markbit operations consistent with atomic ones."
>
> Now non-atomic color transition operations return a boolean indicating
> whether the transition succeeded or not.
>
> This allows to replace color check and transition operations with a
> single transition operation. For example:
>
> if (IsWhite(object)) {
> WhiteToBlack(object);
> Foo();
> }
>
> becomes
>
> if (WhiteToBlack(object)) {
> Foo();
> }
>
> BUG=chromium:694255
>
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
>
> Review-Url: https://codereview.chromium.org/2860323003
> Cr-Commit-Position: refs/heads/master@{#45123}
> Committed: c0a65cd295TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2863953002
Cr-Commit-Position: refs/heads/master@{#45127}
This adaptation will allow build v8 when the component is defined as
shared library. Without this, at linking phase of the unittests will be
displayed error messages for undefined references.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2853483002
Cr-Commit-Position: refs/heads/master@{#45126}
This makes sure that only the "asm-js.h" header is exposed to outside
the directory holding the asm.js validator. It ensures that internals
don't leak out of that component, unless they are explicitly exposed
through the defined interface.
R=clemensh@chromium.org
BUG=v8:6127
Change-Id: I7c41782254cfce102af8edf4356205cfca904e60
Reviewed-on: https://chromium-review.googlesource.com/496147
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45125}
The collection builtins (Map, Set, WeakMap, WeakSet) are still written
in JavaScript and make heavy use of %_ClassOf, which is kind of
expensive compared to a simple instance type check. Change that to use
simple instance type checks instead.
R=jarin@chromium.org
BUG=v8:6261,v8:6278,v8:6344
Review-Url: https://codereview.chromium.org/2814773005
Cr-Original-Commit-Position: refs/heads/master@{#45106}
Committed: 28170099fd
Review-Url: https://codereview.chromium.org/2814773005
Cr-Commit-Position: refs/heads/master@{#45124}
Now non-atomic color transition operations return a boolean indicating
whether the transition succeeded or not.
This allows to replace color check and transition operations with a
single transition operation. For example:
if (IsWhite(object)) {
WhiteToBlack(object);
Foo();
}
becomes
if (WhiteToBlack(object)) {
Foo();
}
BUG=chromium:694255
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2860323003
Cr-Commit-Position: refs/heads/master@{#45123}
When a virtual object passes by a store node that updates a field to the existing value, then the object and its state were not copied, which lead to the original object being passed on.
If then later the store actually modifies and copies the virtual object, this new copy is not passed down the effect chain, so subsequent nodes still refer to the original virtual object and try to update it once new information flows in.
This conflicts with updates on the node that originally created the virtual object, leading to divergence.
Bug: v8:6345
Change-Id: Iab1ce98a60b48478b343eae765c80bdfcb8ba390
Reviewed-on: https://chromium-review.googlesource.com/496267
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45120}
Revert "[heap] Make non-atomic markbit operations consistent with atomic ones."
This reverts commit dd37366fb5
Revert "[heap] Use atomic marking operations in incremental marking if"
This reverts commit 1f2c3596e9
Revert "[heap] Prepare IncrementalMarking::VisitObject for concurrent marking."
This reverts commit 00d1e2cf76
Revert "[heap] Use shared markbits in the concurrent marker."
This reverts commit b0db0541eehttps://codereview.chromium.org/2857713002 blocks the current roll:
https://codereview.chromium.org/2857423002/
Doesn't revert cleanly.
NOTRY=true
TBR=ulan@chromium.org
Bug: chromium:694255
Change-Id: Iada35af5c2529cd9e604802700604b16cc30aa2d
Reviewed-on: https://chromium-review.googlesource.com/497387
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45118}
New test262 tests bring up a couple cases with async arrow functions
that V8 didn't seem to handle properly; this patch makes those cases
errors:
- async (...x,) => y -- Rest parameter must be last formal parameter
- async (...x = z) => y -- No default value for rest parameter
- async (...x, y) => z -- Rest parameter must be last formal parameter
Bug: v8:4483, v8:5051
Change-Id: I024d9ba0c854e8e5e75283df2ee53127b1be090d
Reviewed-on: https://chromium-review.googlesource.com/496057
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#45116}
http://unicode.org/cldr/trac/ticket/9943 added a new separate timezone
ID (Etc/UTC) distinct from "Etc/GMT" even though their behavior is
identical. This CLDR change led v8 to violate Ecma 402 requirement that
resolvedOptions().timeZone for DateTimeFormat be "UTC" for "Etc/UTC"
, "Etc/GMT", "GMT" and "UTC".
This CL made v8 compliant to Ecma 402 again.
Bug=v8:6252
TEST=intl/date-format/timezone
Change-Id: Ibe5d3a2a09680ae00de0d73d123a389710c15af0
Change-Id: Ibe5d3a2a09680ae00de0d73d123a389710c15af0
Reviewed-on: https://chromium-review.googlesource.com/496406
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45114}
This saves about 5% of memory and node count consumed by graph building
on the TypeScript benchmark. High watermark goes down by 3-4%.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2829093002
Cr-Commit-Position: refs/heads/master@{#45113}
We need the job_'s context to reify errors, for example.
Some tasks already managed their context, so centralized
that logic in a SyncCompileTask all sync tasks derive from.
Bug:
Change-Id: I90f462476b47bb8d5777db93d8dfb5c72fbd885b
Reviewed-on: https://chromium-review.googlesource.com/495392
Commit-Queue: Mircea Trofin <mtrofin@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45112}
Port 662aa425ba
Original Commit Message:
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6246
LOG=N
Review-Url: https://codereview.chromium.org/2861863003
Cr-Commit-Position: refs/heads/master@{#45111}
Removes the do-expression wrapping, modifies BytecodeGenerator change
to enter a class literal's block scope if needed.
This does not solve the actual bug in v8:6322, but helps mitigate it in
simple cases. The bug is caused by BytecodeGenerator not allocating a
large enough array of context registers to hold its entire stack,
allowing non-context registers to be overwritten during PushContext and
PopContext bytecodes.
Nevertheless, I like the idea of not depending on do-expressions when
possible, so I think it's worth doing anyways.
BUG=v8:6322
R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
Reviewed-on: https://chromium-review.googlesource.com/491074
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45110}
Different Intl features (DateTimeFormat, NumberFormat, etc) have
different lists of locales supported. Previously, the default locale
was set to "und", as opposed to what was detected from the surrounding
system, if any of these features was missing data. With this patch,
only that feature is set to "und". In this way, the data quality should
be just as good as if there were no fallback logic, but at the same time,
resolvedOptions().locale should show the locale actually in effect.
R=adamk,jshin
BUG=v8:6288
Change-Id: I62b083a1dde2465cb1541cb18ecc7e59f9097bc0
Reviewed-on: https://chromium-review.googlesource.com/492886
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45109}
The collection builtins (Map, Set, WeakMap, WeakSet) are still written
in JavaScript and make heavy use of %_ClassOf, which is kind of
expensive compared to a simple instance type check. Change that to use
simple instance type checks instead.
R=jarin@chromium.org
BUG=v8:6261,v8:6278,v8:6344
Review-Url: https://codereview.chromium.org/2814773005
Cr-Commit-Position: refs/heads/master@{#45106}
If an ArrayBuffer is setup through the WebAssembly.Memory constructor, identify these with a flag and avoid optimizations in js-typed-lowering.cc. This is needed becasue buffers associated with memory objects can be grown/detached leading to crashes.
BUG=chromium:717194
Review-Url: https://codereview.chromium.org/2862763002
Cr-Commit-Position: refs/heads/master@{#45105}
- Removes primitive shuffle opcodes.
- Adds Shuffle opcode for S32x4, S16x8, S8x16.
- Adds code to ARM instruction selector to pick best opcodes for some
common shuffle patterns.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2847663005
Cr-Commit-Position: refs/heads/master@{#45104}
Now that the optimized code hangs off the feedback vector, it is possible
to check whether a function has optimized code available every time it's
called in the interpreter entry trampoline. If optimized code exists, the
interpreter entry trampoline 'self-heals' the closure to point to the
optimized code and links the closure into the optimized code list.
BUG=v8:6246
Change-Id: If1bd7c555bb0551bfe04b36baa6bcf949604717e
Reviewed-on: https://chromium-review.googlesource.com/488026
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45103}
Keeping the CQ bot experimental for now. Will be converted to a regular bot in a follow up.
NOTRY=true
NOTREECHECKS=true
Bug: v8:6355
Change-Id: I094cc26c8fd89bc6fda761d6bfd848a5e3b6dcb5
Reviewed-on: https://chromium-review.googlesource.com/496186
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45100}
The concurrent marker now colors objects grey and black using
the atomic markbit operations.
The heap visitor is changed in two ways:
1) It iterates the map pointer of each object.
2) It guards object visitation with a predicate, which is overridden
in the concurrent marker with the result of GreyToBlack transition.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2855003004
Cr-Commit-Position: refs/heads/master@{#45099}
Storing a data property on |target| can change |source|'s map
if |target| and |source| are the same object.
BUG=chromium:716520
Review-Url: https://codereview.chromium.org/2855133006
Cr-Commit-Position: refs/heads/master@{#45097}
This flag generates false positives, since gcc inlines functions and
propagates constants, and then applies the check.
Drive-by: Refactor the checks that triggered the error to avoid
explicit casts.
R=jochen@chromium.org, machenbach@chromium.org
BUG=v8:6341
Change-Id: I86aebf402cbd2502ef17622a000a5bb777fd4b43
Reviewed-on: https://chromium-review.googlesource.com/494474
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45096}
Currently the VisitObject function iterates the object and then colors
it black. This does not work well with concurrent marking. The function
should instead first try to mark the object black and iterate its body
only if the color transition succeeds.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2853323003
Cr-Commit-Position: refs/heads/master@{#45095}
These wrappers wouldn't be found by the marker otherwise and are only
reported upon the next marking step or GC which potentially is already
too late; the embedder could've reclaimed those objects already.
BUG=chromium:717480
Review-Url: https://codereview.chromium.org/2860753003
Cr-Commit-Position: refs/heads/master@{#45094}
concurrent marking is enabled.
This patch adds kAtomicity flag to IncrementalMarking that is set
depending on the concurrent marking compile time flag.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2857743002
Cr-Commit-Position: refs/heads/master@{#45091}
So far the Array.prototype.pop lowering in the JSBuiltinReducer was
limited to (holey) fast or fast-smi elements. But it can be made to
work easily to also handle fast-double elements, so allow that as
well.
R=jarin@chromium.org
BUG=v8:5267,v8:6338
Review-Url: https://codereview.chromium.org/2861443006
Cr-Commit-Position: refs/heads/master@{#45090}
Reason for revert:
The decision for the specification was to not have this syntax, and instead the syntax before this patch.
Original issue's description:
> [regexp] Support unicode capture names in non-unicode patterns
>
> This ensures that capture names containing surrogate pairs are parsed
> correctly even in non-unicode RegExp patterns by introducing a new
> scanning mode which unconditionally combines surrogate pairs.
>
> BUG=v8:5437,v8:6192
>
> Review-Url: https://codereview.chromium.org/2791163003
> Cr-Commit-Position: refs/heads/master@{#44466}
> Committed: a8651c5671R=yangguo@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2859933003
Cr-Commit-Position: refs/heads/master@{#45088}
Make sure that the input to ChangeFloat64ToTagged is definitely of type
Number, because the operator cannot deal with non-Number inputs.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2858153003
Cr-Commit-Position: refs/heads/master@{#45087}
The functions are validated later during graph generation.
This change uncovered a memory leak, which is now also fixed.
R=ahaas@chromium.org
Change-Id: I0150817da131c5c611fe21b156da9d9d00d4827d
Reviewed-on: https://chromium-review.googlesource.com/490088
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45086}
Now non-atomic color transition operations return a boolean indicating
whether the transition succeeded or not.
This allows to replace color check and transition operations with a
single transition operation. For example:
if (IsWhite(object)) {
WhiteToBlack(object);
Foo();
}
becomes
if (WhiteToBlack(object)) {
Foo();
}
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2857713002
Cr-Commit-Position: refs/heads/master@{#45085}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
1. Generalize context specialization such that the provided context
can be any outer context of the function, not necessarily the
immediate outer context.
2. Based on this: if function specialization is disabled, then
specialize for the module context if there is one.
3. Extend typed lowering of module loads and stores such that if
the operand is a Module constant, we constant-fold the cell load.
That is, a JSLoadModule with a Module HeapConstant input becomes
a LoadField with a Cell HeapConstant input, and similarly for
JSStoreModule.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2841613002
Cr-Commit-Position: refs/heads/master@{#45083}
