Also make it possible to use the background parser from a character
stream. The External{One,Two}ByteStringUtf16CharacterStreams work both
on foreground and background threads.
BUG=v8:5215
R=marja@chromium.org,vogelheim@chromium.org
Review-Url: https://codereview.chromium.org/2195603002
Cr-Commit-Position: refs/heads/master@{#38162}
In contrast to the generic stream, this character stream works without
accessing the heap, and can be used on a background thread.
BUG=v8:5215
R=vogelheim@chromium.org,marja@chromium.org
Review-Url: https://codereview.chromium.org/2184393002
Cr-Commit-Position: refs/heads/master@{#38154}
This slightly simplifies scope handling. It also makes it possible to
implement some potential future changes to classes purely in the parser
by adding additional code to the DoExpression.
This is a portion of https://codereview.chromium.org/2142333002/, which
probably isn't going through in full.
Review-Url: https://codereview.chromium.org/2176653003
Cr-Commit-Position: refs/heads/master@{#38035}
This patch parametrizes AstTraversalVisitor by the actual subclass,
in a similar way as AstVisitor is parametrized. This allows a
subclass to, e.g., override the Visit method and still use the
traversal mechanism. It also allows the subclass to override the
specific visiting methods, without them being virtual.
This patch also removes AstExpressionVisitor, subsuming its
functionality in AstTraversalVisitor.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2169833002
Cr-Commit-Position: refs/heads/master@{#37998}
The uses_arguments() bool is not needed for correct
behavior, since that same information is available after scope analysis
based on whether we allocated the Scope::arguments_ var.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2168293002
Cr-Commit-Position: refs/heads/master@{#37990}
This replaces the AstVisitor approach for scope rewriting with a Scope-only
solution, using a new Scope::Snapshot object that keeps track of inner scopes,
unresolved variables, and temps.
The only use of the AstVisitor is now for parameter varblock scopes introduced
due to sloppy eval in parameters, which greatly simplifies the rewriter
as it no longer needs to handle temps. A future CL may be able to
eliminate it altogether by taking a snapshot per function argument.
Based on verwaest's https://codereview.chromium.org/2166023002/.
BUG=v8:5226
Review-Url: https://codereview.chromium.org/2171703004
Cr-Commit-Position: refs/heads/master@{#37989}
This is in preparation to implementing exception prediction for async
functions. Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.
To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.
The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
It's anyway just the "same" AstNodeFactory (i.e., it's passed the same
AstValueFactory), so no need to have several of them for each
FunctionState.
R=verwaest@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2169823002
Cr-Commit-Position: refs/heads/master@{#37938}
NewScope automatically uses scope(), whereas NewScopeWithParent can pass along any local Scope* as outer scope. The number of calls to NewScopeWithParent should be reduced over time.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2164943002
Cr-Commit-Position: refs/heads/master@{#37912}
It's the only Scope type that has outer scope nullptr; and it always has outer scope nullptr.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2158913005
Cr-Commit-Position: refs/heads/master@{#37907}
This additionally makes the invariant obvious that outer_scope==nullptr+is_with_scope is impossible.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2165923002
Cr-Commit-Position: refs/heads/master@{#37902}
This creates the guarantee that we can compute the parent scope later on. We'll do the same for other types of scopes as well (with perhaps a limited number of exceptions that will need to be eagerly allocated).
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2168563002
Cr-Commit-Position: refs/heads/master@{#37898}
Using Isolate is unsafe, because we might parse (and do scope analysis)
on a background thread.
The illegal access happens when encountering f(arguments) { ... }.
Kudos to verwaest@ for finding this bug.
R=verwaest@chromium.org, rossberg@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158343002
Cr-Commit-Position: refs/heads/master@{#37893}
This frees up a field in Scope and untangles scope a little from the parser.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2160943004
Cr-Commit-Position: refs/heads/master@{#37887}
In a few places in the parser base, we were forced to initialize
variables of type ExpressionT even if it's not necessary, as they
are assigned to later on before their use. This was required
because, for the case of the preparser, ExpressionT is
PreParserExpression which had no default constructor.
This patch adds a default constructor, equivalent to EmptyExpression
for this class, and gets rid of the unnecessary initializations.
R=adamk@chromium.org, littledan@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2162763003
Cr-Commit-Position: refs/heads/master@{#37884}
This reduces memory usage when parsing (because temp_zones are discarded
every now and then) and work done by FuncNameInferrer.
BUG=
Review-Url: https://codereview.chromium.org/2156013002
Cr-Commit-Position: refs/heads/master@{#37863}
This will allow us to move more state from Scope into ScopeState and lazily allocate full Scopes only when needed.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2160593002
Cr-Commit-Position: refs/heads/master@{#37858}
Highlights:
- Record all imports and exports in the ModuleDescriptor.
- Remove ImportDeclaration; instead, introduce a new variable kind for imports.
- Set name on default exported anonymous functions.
Still to do: declaration of namespace imports.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2108193003
Cr-Commit-Position: refs/heads/master@{#37815}
This replaces the vtable on AstNode with a NodeType tag. The visitors replace double dispatch with a single switch over the NodeType.
For now, visitors with subclasses still have virtual methods themselves. We should probably specialize them later as well.
The uint8_t NodeType allows us to better pack memory, saving 8-16 bytes on many AST nodes (with additional packing that I'll do in a follow-up CL)
BUG=
Review-Url: https://codereview.chromium.org/2142233003
Cr-Commit-Position: refs/heads/master@{#37788}
Annex B.3.3 of the spec requires that sloppy-mode block-scoped functions
declared by "eval" are hoisted unless doing so would cause an early
error (which is to say, conflict with a lexical declaration). This patch
amends the check for conflicting declarations to include those outside
of the eval itself.
BUG=v8:4468, v8:4479
Review-Url: https://codereview.chromium.org/2112163002
Cr-Commit-Position: refs/heads/master@{#37783}
Instead of unconditionally parsing the catch parameter as an expression
and then recovering if it turns out to be a simple variable proxy
(the overwhelmingly common case), this patch peeks one token ahead
before attempting to parse. This avoids doing the usual RemoveUnresolved
gymnastics in ParseTryStatement, and as a side-effect slightly improves
function name inference for an async arrow function test case.
Review-Url: https://codereview.chromium.org/2151433005
Cr-Commit-Position: refs/heads/master@{#37780}
Reason for revert:
Correcting issue.
Original issue's description:
> Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ )
>
> Reason for revert:
> Fuzzer claims `try { \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.
>
> Original issue's description:
> > Add errors for declarations which conflict with catch parameters.
> >
> > Catch parameters are largely treated as lexical declarations in the
> > block which contains their body for the purposes of early syntax errors,
> > with some exceptions outlined in B.3.5. This patch introduces most of
> > those errors, except those from `eval('for (var e of ...);')` inside of
> > a catch with a simple parameter named 'e'.
> >
> > Note that annex B.3.5 allows var declarations to conflict with simple
> > catch parameters, except when the variable declaration is the init of a
> > for-of statement.
> >
> > BUG=v8:5112,v8:4231
> >
> > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
> > Cr-Commit-Position: refs/heads/master@{#37462}
>
> TBR=littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5112,v8:4231
>
> Committed: https://crrev.com/8834d5ecb559001c87c42322969471da60574a8c
> Cr-Commit-Position: refs/heads/master@{#37464}
R=littledan@chromium.org
BUG=v8:5112,v8:4231
Review-Url: https://codereview.chromium.org/2119933002
Cr-Commit-Position: refs/heads/master@{#37728}
When the scanner finds a '-->', it's either part of an HTMLCloseComment
or a '--' followed by a '>'. Previously, only a preceding newline would
make it an HTMLCloseComment. Now, a preceding multiline comment also
makes it an HTMLCloseComment. The effect is that now the following is
not a SyntaxError:
x/*
*/-->this is now a comment
BUG=v8:5142
LOG=y
Review-Url: https://codereview.chromium.org/2119763003
Cr-Commit-Position: refs/heads/master@{#37656}
This patch just checks for a stack overflow and returns failure
from the cases which Clusterfuzz found. However, there may be
more locations in the parser which need similar treatment.
R=caitpotter88@gmail.com,neis
BUG=v8:4483,chromium:624300
Review-Url: https://codereview.chromium.org/2135503002
Cr-Commit-Position: refs/heads/master@{#37655}
When reading the value property of an iterator result fails, we must not close the iterator.
This was not discovered earlier because the tests had a subtle bug.
This CL fixes both the desugaring and the tests.
BUG=
Review-Url: https://codereview.chromium.org/2119353002
Cr-Commit-Position: refs/heads/master@{#37571}
For variables introduced as part of a catch pattern, we used to set their
"initializer position" to the beginning of the pattern. This lead to
full-codegen eliminating crucial hole checks when reading such variables
inside the pattern itself.
R=adamk@chromium.org, littledan@chromium.org
BUG=v8:5178
Review-Url: https://codereview.chromium.org/2123953002
Cr-Commit-Position: refs/heads/master@{#37569}
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
Reason for revert:
Fuzzer claims `try { \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.
Original issue's description:
> Add errors for declarations which conflict with catch parameters.
>
> Catch parameters are largely treated as lexical declarations in the
> block which contains their body for the purposes of early syntax errors,
> with some exceptions outlined in B.3.5. This patch introduces most of
> those errors, except those from `eval('for (var e of ...);')` inside of
> a catch with a simple parameter named 'e'.
>
> Note that annex B.3.5 allows var declarations to conflict with simple
> catch parameters, except when the variable declaration is the init of a
> for-of statement.
>
> BUG=v8:5112,v8:4231
>
> Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
> Cr-Commit-Position: refs/heads/master@{#37462}
TBR=littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5112,v8:4231
Review-Url: https://codereview.chromium.org/2112223002
Cr-Commit-Position: refs/heads/master@{#37464}
Catch parameters are largely treated as lexical declarations in the
block which contains their body for the purposes of early syntax errors,
with some exceptions outlined in B.3.5. This patch introduces most of
those errors, except those from `eval('for (var e of ...);')` inside of
a catch with a simple parameter named 'e'.
Note that annex B.3.5 allows var declarations to conflict with simple
catch parameters, except when the variable declaration is the init of a
for-of statement.
BUG=v8:5112,v8:4231
Review-Url: https://codereview.chromium.org/2109733003
Cr-Commit-Position: refs/heads/master@{#37462}
Previously, any expressions inside destructuring patterns in a catch
would be parsed in the surrounding scope, instead of in the catch's
scope. This change fixes that by entering not only the catch scope,
but also the block scope inside it.
R=neis@chromium.org
BUG=v8:5106, v8:5112
Review-Url: https://codereview.chromium.org/2110193002
Cr-Commit-Position: refs/heads/master@{#37415}
In ES2016, function declarations nested in blocks are formally allowed. This was
never a part of ECMAScript, but was a common extension. Unfortunately
implementations differed in the exact semantics. Annex B.3.3 in the spec tries
to standardize the parts which are common to different implementations, but does
so with some fairly complicated semantics.
This CL addresses three issues related to annex B.3.3:
* When the outer function had a complex parameter list, no hoisting whatsoever was
being performed.
* Hoisting was not blocked by parameters of the same name.
* Hoisting was not blocked by nested lexical declarations of the same name.
We had tests which checked for the second, but they were incorrectly passing due to
the first. This CL adds more complete tests.
BUG=v8:5151, v8:5111
Review-Url: https://codereview.chromium.org/2099623003
Cr-Commit-Position: refs/heads/master@{#37405}
Add a flag harmony_trailing_commas_in_parameters that allows trailing
commas in function parameter declaration lists and function call
parameter lists. Trailing commas are allowed in parenthetical lists like
`(a, b, c,)` only if the next token is `=>`, thereby making it an arrow
function declaration. Only 1 trailing comma is allowed, not `(a,,)`. A
trailing comma must follow a non-rest parameter, so `(,)` and `(...a,)`
are still SyntaxErrors. However, a trailing comma is allowed after a
spread parameter, e.g. `a(...b,);`.
Add parser tests for all of the above.
BUG=v8:5051
LOG=y
Review-Url: https://codereview.chromium.org/2094463002
Cr-Commit-Position: refs/heads/master@{#37355}
When re-scoping arrow function parameter initializers, temporaries
should be moved from the closure of the old scope to the closure of
the new scope, if necessary.
R=adamk@chromium.org, rossberg@chromium.org
BUG=chromium:622663
LOG=N
Review-Url: https://codereview.chromium.org/2083083007
Cr-Commit-Position: refs/heads/master@{#37335}
When calling the throw method on a generator suspended inside a yield*, yield*
in turn tries to call throw on its iterable. If the iterable does not provide a
throw method, yield* must try to call the return method instead and then throw a
TypeError. Due to a bug in our desugaring, we never threw the TypeError.
R=adamk@chromium.org
BUG=v8:5132
Review-Url: https://codereview.chromium.org/2094253002
Cr-Commit-Position: refs/heads/master@{#37314}
When calling the return method on a generator suspended inside a yield*, yield*
in turn calls return on its iterable. If this results in a "done" iterator,
yield* must return immediately, thus terminating the generator. For some
reason, we didn't terminate the generator but continued right after the yield*.
R=adamk@chromium.org
BUG=v8:5131
Review-Url: https://codereview.chromium.org/2100093002
Cr-Commit-Position: refs/heads/master@{#37310}
While we properly handled scopes of initializers in destructured parameters,
we never did the right thing for computed properties. This patch fixes that
by factoring out PatternRewriter's scope rewriting logic and calls it
for the computed property case.
BUG=chromium:620119
Review-Url: https://codereview.chromium.org/2084103002
Cr-Commit-Position: refs/heads/master@{#37228}
Reason for revert:
Infra issue appears to be over
TBR=adamk@chromium.org
Original issue's description:
> Revert of Rewrite scopes of non-simple default arguments (patchset #5 id:80001 of https://codereview.chromium.org/2077283004/ )
>
> Reason for revert:
> Seems to close tree (but it could be an infra issue)
>
> Original issue's description:
> > Rewrite scopes of non-simple default arguments
> >
> > Default parameters have additional declaration block scopes inserted
> > around them when something in the function scope calls eval. This
> > patch sets the parent scope of the expressions introduced due to
> > those defaults to the new block scope.
> >
> > R=adamk
> > BUG=chromium:616386
> >
> > Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> > Cr-Commit-Position: refs/heads/master@{#37198}
>
> TBR=adamk@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:616386
>
> Committed: https://crrev.com/dd50262933d2ac087da32be887a7c18385fd998e
> Cr-Commit-Position: refs/heads/master@{#37201}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2086353003
Cr-Commit-Position: refs/heads/master@{#37202}
Reason for revert:
Seems to close tree (but it could be an infra issue)
Original issue's description:
> Rewrite scopes of non-simple default arguments
>
> Default parameters have additional declaration block scopes inserted
> around them when something in the function scope calls eval. This
> patch sets the parent scope of the expressions introduced due to
> those defaults to the new block scope.
>
> R=adamk
> BUG=chromium:616386
>
> Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> Cr-Commit-Position: refs/heads/master@{#37198}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2081323006
Cr-Commit-Position: refs/heads/master@{#37201}
Default parameters have additional declaration block scopes inserted
around them when something in the function scope calls eval. This
patch sets the parent scope of the expressions introduced due to
those defaults to the new block scope.
R=adamk
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2077283004
Cr-Commit-Position: refs/heads/master@{#37198}
Previously, an async arrow function would be parsed if any valid
ConditionalExpression began with the identifier "async", and its following token
was on the same line.
So for example, `async.bar foo => 1` was parsed as a valid async arrow function.
This patch corrects this behaviour by asserting that the following token is a
valid arrow parameters start.
BUG=v8:4483
R=littledan@chromium.org, henrique.ferreiro@gmail.com
Review-Url: https://codereview.chromium.org/2089733002
Cr-Commit-Position: refs/heads/master@{#37154}
This runtime function now also works for Ignition generators. It returns the
source position of the yield at which a suspended generator got suspended. This
works by storing the current bytecode offset at suspension and using an existing
mechanism to map it back to a source position.
TBR=littledan@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2079613003
Cr-Commit-Position: refs/heads/master@{#37140}
Runtime_DeclareLookupSlot is used when generating code for var and function declarations
originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes:
- With legacy const gone, lookup slots never have any property attributes.
- There was a bit signaling that the variable was from an eval, but that was redundant since
DeclareLookupSlot is only used for eval.
- Some Proxy-related code didn't make sense here.
Its name was also not terribly clear: while "LookupSlot" is used in several places, this
particular function is only used for declaring variables and functions inside sloppy eval.
Renamed (and split into two) to make this clear for future archeologists.
Also added various DCHECKs to check the assumptions being made.
Review-Url: https://codereview.chromium.org/2061173002
Cr-Commit-Position: refs/heads/master@{#37111}
Reporting use counts by invoking a callback once per occurrence has
a large overhead cost in certain situations, for example when it needs
to be dispatched to a different thread (which is the case for Web Workers).
Parsing large scripts can produce a lot of occurrences (strict/sloppy mode
once per function).
Chromium (the only known user of UseCounters so far) does not actually care
about number of occurrences, but simply whether they happened at least once.
This commit changes behavior to report features at most once, which dramatically
improves performance for impacted use cases, and should not affect the only
known real world usage.
R=littledan@chromium.org
BUG=chromium:614775
Review-Url: https://codereview.chromium.org/2062203002
Cr-Commit-Position: refs/heads/master@{#36979}
Reason for revert:
Does not fix the bug it intended to fix.
Original issue's description:
> Fix scope flags for default parameters
>
> R=rossberg,adamk
> BUG=chromium:616386
>
> Committed: https://crrev.com/4cc1331c341f5bfbeee54fec521f682a8a406af4
> Cr-Commit-Position: refs/heads/master@{#36755}
TBR=adamk@chromium.org,rossberg@chromium.org,jochen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2062593002
Cr-Commit-Position: refs/heads/master@{#36976}
This patch declares a new rest parameter for the derived constructor,
and passes it to base constructor after calling PrepareSpreadArguments.
This patch also updates the test262.status to account for
the now passing test.
BUG=v8:4890
Review-Url: https://codereview.chromium.org/2056993004
Cr-Commit-Position: refs/heads/master@{#36939}
It seems that I forgot to remove the DCHECK when refactoring this
function, even though the comment had it right. It also seems that
this is hard to trigger. The minimal example I found, after fuzzer's
bug, was:
eval, x[eval]
R=adamk@chromium.org
BUG=chromium:619476
LOG=N
Review-Url: https://codereview.chromium.org/2058413002
Cr-Commit-Position: refs/heads/master@{#36929}
This patch attempts to reduce the (stack) memory footprint of
expression classifiers. Instead of keeping space in each
classifier for all possible error messages that will
(potentially) be reported, if an expression turns out to be
a pattern or a non-pattern, such error messages are placed in
a list shared by the FunctionState and each classifier keeps a
couple of indices in this list. This requires that classifiers
are used strictly in a stack-based fashion, which is also in line
with my previous patch for revisiting non-pattern rewriting.
R=adamk@chromium.org
BUG=chromium:528697
Review-Url: https://codereview.chromium.org/1708193003
Cr-Commit-Position: refs/heads/master@{#36897}
In commit b3bfc0bd58, I corrected the source
position of yield-exceptions by not setting the "return position" on returns
that correspond to yields. It turns out that this caused a bug with debug
stepping. The proper fix is to keep the return position on those returns but
additionally attach the yield's source position to the Throw emitted in
VisitYield.
R=rmcilroy@chromium.org, yangguo@chromium.org
BUG=v8:4907
Review-Url: https://codereview.chromium.org/2051783002
Cr-Commit-Position: refs/heads/master@{#36896}
We ported hashmap.h into libsampler as a workaround before, so the main focus of
this patch is to reduce code duplication. This patch moves the hashmap into
src/base as well as creates DefaultAllocationPolicy using malloc and free.
BUG=v8:5050
LOG=n
Review-Url: https://codereview.chromium.org/2010243003
Cr-Commit-Position: refs/heads/master@{#36873}
We have fast-paths in identifier and string scanning that know that so far they have only handled one-byte input. In that case, we can add chars to the literal buffer assuming that it's still in one-byte state, avoiding 2 branches. This seemingly reduces identifier scanning from ~5% to ~4% on octane-codeload.
BUG=
Review-Url: https://codereview.chromium.org/2044233004
Cr-Commit-Position: refs/heads/master@{#36868}
Annex B 3.3 applies only for ordinary FunctionDeclarations, not
GeneratorDeclarations or AsyncFunctionDeclarations. This patch
- Skips applying Annex B 3.3 to async functions
- Adds a flag to refrain from applying it to generators
- UseCounter for how often duplicate function in block occurs
with generators (unclear how to measure need for hoisting from block)
BUG=v8:4806
Review-Url: https://codereview.chromium.org/1995863002
Cr-Commit-Position: refs/heads/master@{#36557}
Commit c86f189 corrected the way context from which a specific error is
thrown, but the in-line comment was not updated to reflect this.
Update the comment to accurately describe the intended behavior.
LOG=N
R=littledan@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/1999483002
Cr-Commit-Position: refs/heads/master@{#36541}
Also change parser to insert %_GeneratorClose instead of %GeneratorClose.
Full-codegen generators will fall back to the runtime function.
BUG=v8:4907
Review-Url: https://codereview.chromium.org/1993073003
Cr-Commit-Position: refs/heads/master@{#36401}
Some IdentifierNames are only included in the set of FutureReservedWords
for strict mode code. Outside of strict mode, these IdentifierNames may
be used as Identifiers. Notably, this includes their use as
BindingIdentifiers in LexicalBindings.
From ES2015 12.1.1 Static Semantics: Early Errors (Identifiers):
> It is a Syntax Error if this phrase is contained in strict mode code
> and the StringValue of IdentifierName is: "implements", "interface",
> "let", "package", "private", "protected", "public", "static", or
> "yield".
http://www.ecma-international.org/ecma-262/6.0/#sec-identifiers-static-semantics-early-errors
Due to a error in its heuristic for disambiguating the `let` token, V8
does not currently allow any of the strict-mode-only FutureReservedWords
to be used as a BindingIdentifier outside of strict mode.
Update V8's heuristic for disambiguating the `let` keyword to account
for strict mode, enabling these IdentifierNames to be used
BUG=v8:4918
LOG=N
R=adamk@chromium.org
Review-Url: https://codereview.chromium.org/1891453005
Cr-Commit-Position: refs/heads/master@{#36296}
This changes the parser to keep around bodies for asm.js functions when
then asm.js validator is turned on. Eventually the validator will work
on one function at a time, but for now we validate the entire module at
once.
R=rossberg@chromium.org
Review-Url: https://codereview.chromium.org/1981333003
Cr-Commit-Position: refs/heads/master@{#36291}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
Ordinary arrow functions have 'undefined' in their frame's receiver.
Generators restore the receiver to the frame based on one passed in
when they are constructed in CreateJSGeneratorObject.
This patch makes async arrow functions pass in 'undefined' for their
receiver so that they have the same behavior as ordinary arrow
functions, which avoids the issue of encountering TDZ when calling
an async arrow function in a subclass constructor before a super
call has returned.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/1976813002
Cr-Commit-Position: refs/heads/master@{#36264}
By fully annotating the API with runtime counters we can properly measure
how much time we spend in total in v8. When --runtime-call-stats is specified
we now disable the fast-paths for callbacks to properly measure them.
As a drive-by-fix this CL unifies the LOG messages in api.cc.
Additionally we added missing timers to gain better resolution in the parser
and callbacks.
BUG=
Review-Url: https://codereview.chromium.org/1923893002
Cr-Commit-Position: refs/heads/master@{#36248}
Also make all AstVisitors consistently visit all the relevant parts
of ForOfStatement. PrettyPrinter no longer fares well, but given
how much desugaring happens to ForOf in the parser, any pretty-printed
view of it isn't going to be human readable. AstPrinter, on the other
hand, now gives a realistic view of what's been generated for for-of.
Review-Url: https://codereview.chromium.org/1968753004
Cr-Commit-Position: refs/heads/master@{#36215}
When the rewriter moves a temporary variable between scopes, it must
be sure to maintain the order, so that the rewritten order is the
same as it would have been without rewriting.
To expose the difference in behavior, this patch removes the superfluous
visitation of ForOfStatement::each() from AstExpressionVisitor, which
happened to be the only thing keeping all the temporaries in order
in mjsunit/harmony/regress/regress-crbug-578038.js. Without the proper
order, this test would fail under --stress-opt, because the ".for"
variable (behind the "each" proxy) would get two different positions
in the scope, one on first parse (with rewriting) and the other on
second parse (lazy parsing for optimization).
A follow-up patch will remove each() and iterable() from ForOfStatement
altogether, but I wanted to keep this patch small to highlight exactly
the bit of code needed to make the test pass when not visiting each().
BUG=v8:4791
LOG=n
Review-Url: https://codereview.chromium.org/1784893003
Cr-Commit-Position: refs/heads/master@{#36150}
Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
--harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
BUG=v8:4915
LOG=N
Review-Url: https://codereview.chromium.org/1928203002
Cr-Commit-Position: refs/heads/master@{#36024}
Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.
Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.
BUG=v8:4970
LOG=n
Review-Url: https://codereview.chromium.org/1931003003
Cr-Commit-Position: refs/heads/master@{#36001}
PushBack(end-of-input) is a little weird, but since
Utf16CharacterStream::Advance will advance pos_m, but not buffer_cursor_
when at the end of the stream, pushing back the end-of-input token needs
to do the exact inverse.
(The reason Advance does not advance buffer_cursor_ is that buffer_cursor_ is often dereferenced
directly to access memory and so always needs to point to, well, memory.)
(The PushBack implementation for all other streams looks correct.)
R=rossberg@chromium.org
BUG=chromium:607903
LOG=Y
Review-Url: https://codereview.chromium.org/1941843002
Cr-Commit-Position: refs/heads/master@{#35968}
Yield expressions are not allowed in formal parameter initializers of
generators, but we weren't properly catching the case where the yield
expression appeared in the 'extends' clause of a class expression.
They also aren't allowed in arrow functions, which we were failing to
catch due to not looking at the obscurely-named "FormalParameterInitializerError"
bit of ExpressionClassifier.
This patch passes along an ExpressionClassifier when parsing class
expressions and accumulates the proper error for that case.
For the arrow function case, the fix is simply to check for the
"formal parameter initializer" error once we know we've parsed
an arrow function. The error message used for this has also
been made specific to yield expressions.
Tests are added both for the error case and the non-error cases (where
yield is used in such a position inside the class body).
BUG=v8:4966, v8:4968, v8:4974
LOG=n
Review-Url: https://codereview.chromium.org/1941823003
Cr-Commit-Position: refs/heads/master@{#35957}
Restrict the use of the `await` token as an identifier when parsing
source text as module code.
From
http://www.ecma-international.org/ecma-262/6.0/#sec-future-reserved-words:
> 11.6.2.2 Future Reserved Words
>
> The following tokens are reserved for used as keywords in future
> language extensions.
>
> Syntax
>
> FutureReservedWord ::
> enum
> await
>
> await is only treated as a FutureReservedWord when Module is the goal
> symbol of the syntactic grammar.
BUG=v8:4767
LOG=N
R=adamk@chromium.org
Review-Url: https://codereview.chromium.org/1723313002
Cr-Commit-Position: refs/heads/master@{#35914}
The legacy function declaration locations from Annex B 3.2 and 3.4 do not
apply for generator declarations. This patch cracks down on those usages,
which is tested for by new incoming test262 tests.
BUG=v8:4824
LOG=Y
R=adamk
Review-Url: https://codereview.chromium.org/1900033003
Cr-Commit-Position: refs/heads/master@{#35835}
The first version of --harmony-for-in avoided throwing PreParser
errors in order to retain use counting. This patch threads
use_counts_ through to the PreParser to allow use counting in
the PreParser while also throwing errors for this case.
Also slightly refactored the Parser code to do a little less
code duplication.
BUG=v8:4942
LOG=y
Review URL: https://codereview.chromium.org/1913203002
Cr-Commit-Position: refs/heads/master@{#35780}
Refactor the Scope object to automatically enable strict mode when
initialized as a "module" scope, relieving the caller of this
responsibility.
BUG=v8:4941
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1906923002
Cr-Commit-Position: refs/heads/master@{#35730}
This patch introduces new scopes in the preparser, just like they
are introduced by the parser, in the following places:
- blocks
- try statement
- switch statement
- scoped statements, in several places
- for statement
- eager function bodies
R=rossberg@chromium.org
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1906793002
Cr-Commit-Position: refs/heads/master@{#35708}
Our previous over-conservative answer caused us to emit hole checks in
full-codegen when eagerly parsing but not when lazily parsing.
With this patch, we use the positions of the BinaryOperations making up
the parameter list (which are the positions of the commas) to determine
the appropriate "end position" for each parameter's initializer. This means
that we get accurate-enough positions for the initializers in the eager
parsing step to get the same answers for hole-check-elimination that we
will later during ParseLazy.
In the included test case, for example:
(function() { ((s = 17, y = s) => s)(); } )();
^2 ^1
The old code would generate a hole check when trying to load
|s| for assignment to |y| (because it treated the closing parentheses
pointed to by "^1" as the "initialization position" of |s|).
The new code uses the comma pointed to by "^2" as the initialization
position of |s|. Since that occurs textually before the load of |s|,
full-codegen knows it can avoid the hole check.
BUG=v8:4908
LOG=n
Review URL: https://codereview.chromium.org/1900343002
Cr-Commit-Position: refs/heads/master@{#35678}
[15.2.1.11 Static Semantics:
LexicallyDeclaredNames](https://tc39.github.io/ecma262/#sec-module-semantics-static-semantics-lexicallydeclarednames)
(in contrast with its definition for StatementListItem) makes no
explicit provision for HoistableDeclarations. This means that function
declarations are treated as lexically scoped in module code, as
described in section 15.2.1.11's informative note:
> At the top level of a function, or script, function declarations are
> treated like var declarations rather than like lexical declarations.
BUG=v8:4884
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1851673007
Cr-Commit-Position: refs/heads/master@{#35633}
Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.
This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.
To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).
Review URL: https://codereview.chromium.org/1895973002
Cr-Commit-Position: refs/heads/master@{#35632}
This patch correctly re-scopes inner scopes that can appear in do
expressions used as initializers to arrow parameters.
R=rossberg@chromium.org
BUG=v8:4904
LOG=N
Review URL: https://codereview.chromium.org/1887743002
Cr-Commit-Position: refs/heads/master@{#35542}
The parser should never need to look at the underlying closure object,
hence the field can be moved from ParseInfo into CompilationInfo.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1863083002
Cr-Commit-Position: refs/heads/master@{#35358}
As originally implemented, a SingleNameBinding within a BindingPattern
was incorrectly interpreted as an assignment if an initializer was
present and that initializer was itself an AssignmentExpresion.
For example:
let x;
{ let [x = y = 1] = []; }
print(x); // expected: undefined, actual: 1
Extend the heuristic that detects the "context" of a destructuring
pattern to account for AssignmentExpressions within SingleNameBindings.
BUG=v8:4891
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1859423002
Cr-Commit-Position: refs/heads/master@{#35334}
Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.
Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.
R=mstarzinger@chromium.org, neis@chromium.orgTBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1865833002
Cr-Commit-Position: refs/heads/master@{#35283}
The parser eagerly rewrites destructuring assignments occuring
in formal parameter initializers, because not doing so would
cause the BindingPattern rewriting to be confused and do the
wrong thing.
This change prevents this rewriting from descending into the
bodies of lazily parsed functions.
In general, it's a mistake to descend into the bodies of function
literals anyways, since they are rewritten separately on their
own time, so there is no distinction made between lazily
"throw away" eagerly parsed functions in the temporary parser
arena, or "real" eagerly parsed functions that will be compiled.
BUG=chromium:594084, v8:811
LOG=N
R=adamk@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1864553002
Cr-Commit-Position: refs/heads/master@{#35277}
This makes sure the SharedFunctionInfo is available whenever we evaluate
the UseIgnition predicate. This makes sure we can apply filters properly
even when the interpreter causes eager compilation (instead of lazy).
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1860943002
Cr-Commit-Position: refs/heads/master@{#35263}
When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it. This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).
This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop. It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.
BUG=v8:4759
LOG=n
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1852703002
Cr-Commit-Position: refs/heads/master@{#35251}
The parser uses a try-catch in order to record when the client of an iterator
throws. The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.
This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
reusing the (not-cleared) pending message
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n
Review URL: https://codereview.chromium.org/1842953003
Cr-Commit-Position: refs/heads/master@{#35226}
We expect that the majority of malloc'd memory held by V8 is allocated
in Zone objects. Introduce an Allocator class that is used by Zones to
manage memory, and allows for querying the current usage.
BUG=none
R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org
LOG=n
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1847543002
Cr-Commit-Position: refs/heads/master@{#35196}
It's been on since M49. Also moved tests from harmony -> es6,
one of which was merged with another test of the same name.
While moving stuff over to regexp.js, I also noticed that there
were unused calls to %FunctionSetName and %SetNativeFlag (those
calls are already handled by InstallGetter()).
Review URL: https://codereview.chromium.org/1838563003
Cr-Commit-Position: refs/heads/master@{#35076}
ES#sec-islabelledfunction specifies that labelled function declarations
may not occur as the body of a control flow construct such as an if
statement. This patch implements those restrictions, which also
eliminates a previous case resulting in a DCHECK failure which is now
a SyntaxError.
BUG=chromium:595309
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1808373003
Cr-Commit-Position: refs/heads/master@{#35049}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
Reason for revert:
Violates ES6 spec (crbug.com/4850), and implementation was over-eager. Will revert for now.
Original issue's description:
> Parser: Make skipping HTML comments optional.
>
> API change: This adds a new flag skip_html_comments to v8::ScriptOriginOptions. This flag controls whether V8 will attempt to honour HTML-style comments in JS sources.
>
> (That is: Gracefully ignore <!-- ... ---> in JS sources, which was a popular technique in the early days of JavaScript, to prevent non-JS-enabled browsers from displaying script sources to uses.)
>
> The flag defaults to 'true' when using v8::ScriptOrigin constructor, which preserves the existing behaviour. Embedders which are happy with the existing behaviour will thus not need any changes.
>
> BUG=chromium:573887
> LOG=Y
>
> Committed: https://crrev.com/91d344288aa51ed03eaaa1cb3e368ac1e82f0173
> Cr-Commit-Position: refs/heads/master@{#34904}
TBR=jochen@chromium.org,rossberg@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:573887, v8:4850
LOG=Y
Review URL: https://codereview.chromium.org/1817163003
Cr-Commit-Position: refs/heads/master@{#34958}
We don't want them to disappear from the stack traces.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1818063002
Cr-Commit-Position: refs/heads/master@{#34957}
This revealed one Mozilla test that depended upon a lack
of early error for "with ({}) function ...". The test
has been marked as failing.
R=littledan@chromium.org
Review URL: https://codereview.chromium.org/1814863005
Cr-Commit-Position: refs/heads/master@{#34910}
API change: This adds a new flag skip_html_comments to v8::ScriptOriginOptions. This flag controls whether V8 will attempt to honour HTML-style comments in JS sources.
(That is: Gracefully ignore <!-- ... ---> in JS sources, which was a popular technique in the early days of JavaScript, to prevent non-JS-enabled browsers from displaying script sources to uses.)
The flag defaults to 'true' when using v8::ScriptOrigin constructor, which preserves the existing behaviour. Embedders which are happy with the existing behaviour will thus not need any changes.
BUG=chromium:573887
LOG=Y
Review URL: https://codereview.chromium.org/1801203002
Cr-Commit-Position: refs/heads/master@{#34904}
It was never being set to false in production (though it was in test-parsing.cc,
due to that test having its own flag-setting logic).
Review URL: https://codereview.chromium.org/1815033002
Cr-Commit-Position: refs/heads/master@{#34878}
The way desugared instanceof called OrdinaryHasInstance if the lookup of
@@hasInstance failed was incorrect.
BUG=v8:4774
LOG=N
Review URL: https://codereview.chromium.org/1812793002
Cr-Commit-Position: refs/heads/master@{#34855}
This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.
As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.
BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1804783002
Cr-Commit-Position: refs/heads/master@{#34802}
Modules already have a separate entrypoint into the engine (at the moment,
this is v8::ScriptCompiler::CompileModule, though that will change to
something like ParseModule). This meant that requiring a commandline flag
simply added an extra complexity burden on embedders. By removing the v8
flag, this lets embedders use their own flagging mechanism (such as d8's
"--module", or Blink's RuntimeEnabledFeatures) to control whether
modules are to be used.
Also remove old modules tests that were being skipped (since they test
very old, pre-ES2015 modules syntax).
R=littledan@chromium.org
BUG=v8:1569, chromium:594639
LOG=y
Review URL: https://codereview.chromium.org/1804693002
Cr-Commit-Position: refs/heads/master@{#34764}
Now that the destructuring flags are gone, we always call
CheckAndRewriteReferenceExpression, so unified the two methods again.
Also cleaned up the code within, e.g. removing unnecessary Scanner::Location
construction.
Review URL: https://codereview.chromium.org/1781933003
Cr-Commit-Position: refs/heads/master@{#34699}
These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.
Also moved the tests out of harmony/ and into es6/.
Review URL: https://codereview.chromium.org/1776683003
Cr-Commit-Position: refs/heads/master@{#34692}
We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of.
This is behind --harmony-iterator-close.
R=adamk@chromium.org
BUG=v8:3566
LOG=Y
Review URL: https://codereview.chromium.org/1772793002
Cr-Commit-Position: refs/heads/master@{#34654}
This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
function.prototype = {
method: function() { ... }
}
Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
BUG=chromium:593008
LOG=n
Review URL: https://codereview.chromium.org/1772423002
Cr-Commit-Position: refs/heads/master@{#34602}
Simply call InitializeForOfStatement (split out from InitializeForEachStatement)
instead, which already has all the necessary logic.
As part of this, trade one bool arg (is_destructuring) for an int
(iterable_pos).
Review URL: https://codereview.chromium.org/1740293002
Cr-Commit-Position: refs/heads/master@{#34561}
Now there is just one kind, corresponding to what was called "initial" before.
Replacement for "suspend": when the parser sees a yield in JS code, it
will turn it into a Yield node but wrap its argument in an iterator result
object. Replacement for "final": the parser simply inserts a return statement
instead.
R=littledan@chromium.org, mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1751613004
Cr-Commit-Position: refs/heads/master@{#34515}
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}
Runtime asserts are were previously a bit annoying to debug, due to
the lack of a useful error message, even in debug mode. This patch
prints out some more information in debug mode for runtime assert
failures while preserving their exception-throwing semantics. While
we're at it, it requires a semicolon after RUNTIME_ASSERT macro
invocations.
```
$ rlwrap out/Debug/d8 --allow-natives-syntax
V8 version 5.1.0 (candidate)
d8> %ArrayBufferNeuter(1)
#
# Runtime error in ../../src/runtime/runtime-typedarray.cc, line 52
#
# args[0]->IsJSArrayBuffer()
==== C stack trace ===============================
1: 0xf70ab5
2: 0xadeebf
3: 0xadedd4
4: 0x2ef17630693b
(d8):1: illegal access
%ArrayBufferNeuter(1)
^
d8>
```
Also give the other 'illegal access' case (a special SyntaxError type) a more
descriptive error message for its sole usage.
R=adamk
Review URL: https://codereview.chromium.org/1748183002
Cr-Commit-Position: refs/heads/master@{#34401}
The preparser should ignore "use strong" if the --strong_mode flag
is not turned on, but this should not stop processing subsequent
directives.
R=rossberg@chromium.org
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1752753002
Cr-Commit-Position: refs/heads/master@{#34392}
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}
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}
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}
of non-pattern expressions, according to the (internally circulated)
design document. Details to be provided here.
1. RewritableAssignmentExpression has been renamed to RewritableExpression.
It is a wrapper for AST nodes that wait for some potential rewriting
(that may or may not happen). Also, Is... and As... macros now see
through RewritableExpressions.
2. The function state keeps a list of rewritable expressions that must be
rewritten only if they are used as non-pattern expressions.
3. Expression classifiers are now templates, parameterized by parser
traits. They keep some additional state: a pointer to the list of
non-pattern rewritable expressions. It is important that expression
classifiers be used strictly in a stack fashion, from now on.
4. The RewriteNonPattern function has been simplified.
BUG=chromium:579913
LOG=N
Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
Cr-Commit-Position: refs/heads/master@{#34154}
Review URL: https://codereview.chromium.org/1702063002
Cr-Commit-Position: refs/heads/master@{#34162}
Reason for revert:
[Sheriff] This makes jsfunfuzz unhappy:
https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7681
Original issue's description:
> This patch implements an alternative approach to the rewriting
> of non-pattern expressions, according to the (internally circulated)
> design document. Details to be provided here.
>
> 1. RewritableAssignmentExpression has been renamed to RewritableExpression.
> It is a wrapper for AST nodes that wait for some potential rewriting
> (that may or may not happen). Also, Is... and As... macros now see
> through RewritableExpressions.
>
> 2. The function state keeps a list of rewritable expressions that must be
> rewritten only if they are used as non-pattern expressions.
>
> 3. Expression classifiers are now templates, parameterized by parser
> traits. They keep some additional state: a pointer to the list of
> non-pattern rewritable expressions. It is important that expression
> classifiers be used strictly in a stack fashion, from now on.
>
> 4. The RewriteNonPattern function has been simplified.
>
> BUG=chromium:579913
> LOG=N
>
> Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
> Cr-Commit-Position: refs/heads/master@{#34154}
TBR=rossberg@chromium.org,bmeurer@chromium.org,titzer@chromium.org,nikolaos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579913
Review URL: https://codereview.chromium.org/1712203002
Cr-Commit-Position: refs/heads/master@{#34158}
of non-pattern expressions, according to the (internally circulated)
design document. Details to be provided here.
1. RewritableAssignmentExpression has been renamed to RewritableExpression.
It is a wrapper for AST nodes that wait for some potential rewriting
(that may or may not happen). Also, Is... and As... macros now see
through RewritableExpressions.
2. The function state keeps a list of rewritable expressions that must be
rewritten only if they are used as non-pattern expressions.
3. Expression classifiers are now templates, parameterized by parser
traits. They keep some additional state: a pointer to the list of
non-pattern rewritable expressions. It is important that expression
classifiers be used strictly in a stack fashion, from now on.
4. The RewriteNonPattern function has been simplified.
BUG=chromium:579913
LOG=N
Review URL: https://codereview.chromium.org/1702063002
Cr-Commit-Position: refs/heads/master@{#34154}
Various syntactic forms now cause functions to have names where they
didn't before. Per the upcoming changes to the toString spec, only
a name that was literally part of a function's expression or declaration
is meant to be reflected in toString. This also happens to be the same
set of names that V8 currently outputs (without the --harmony-function-name
flag).
This required distinguishing anonymous FunctionExpressions from other sorts
of function definitions (like methods and getters/setters) in the AST, parser,
and at runtime.
The patch also takes the opportunity to remove one more argument (and enum)
from FunctionLiteral, as well as adding a special factory method for the
case of a FunctionLiteral representing toplevel or eval'd code.
BUG=v8:4760
LOG=n
Review URL: https://codereview.chromium.org/1712833002
Cr-Commit-Position: refs/heads/master@{#34132}
This frees up one bit in FunctionKind, which I plan to make slightly
more syntactic info about functions available in SharedFunctionInfo
(needed for ES2015 Function.name support).
BUG=v8:3956, v8:4760
LOG=n
Review URL: https://codereview.chromium.org/1704223002
Cr-Commit-Position: refs/heads/master@{#34125}
Implements iterator finalisation by desugaring for-of loops with an additional try-finally wrapper. See comment in parser.cc for details.
Also improved some AST printing facilities while there.
@Ross, I had to disable the bytecode generation test for for-of, because it got completely out of hand after this change (the new bytecode has 150+ lines). See the TODO that I assigned to you.
Patch set 1 is WIP patch by Georg (http://crrev.com/1695583003), patch set 2 relative changes.
@Georg, FYI, I changed the following:
- Moved try-finally out of the loop body, for performance, and in order to be able to handle `continue` correctly.
- Fixed scope management in ParseForStatement, which was the cause for the variable allocation failure.
- Fixed pre-existing zone initialisation bug in rewriter, which caused the crashes.
- Enabled all tests, adjusted a few others, added a couple more.
BUG=v8:2214
LOG=Y
Review URL: https://codereview.chromium.org/1695393003
Cr-Commit-Position: refs/heads/master@{#34111}
This CL adds a TRACE_EVENT where there is an isolated LOG, a HistogramTimer
or a TimerEvent.
Once we have a d8 tracing controller, all TimerEvents will be removed since
they do not provide an added value over TRACE_EVENTs. HistogramTimers will
remain, but their functionality will be limited to Histograms only.
BUG=v8:4562
LOG=N
Review URL: https://codereview.chromium.org/1707563002
Cr-Commit-Position: refs/heads/master@{#34099}
This avoids spending lots of time in Scope::RemoveUnresolved for very long
variable declaration lists.
BUG=v8:4699
LOG=n
Review URL: https://codereview.chromium.org/1655313003
Cr-Commit-Position: refs/heads/master@{#34047}
This is hopefully the last in a series of cleanup patches around
destructuring assignment. It simplifies the ParseAssignmentExpression
API, making the callers call CheckDestructuringElement() where appropriate.
CheckDestructuringElement has been further simplified to only emit the
errors that the parser depends on it emitting.
I've also beefed up the test coverage in test-parsing.cc to
handling all the destructuring flags being on, which caught an oddity
in how we disallow initializers in spreads in patterns (we need to treat
RewritableAssignmentExpressions as Assignments for the purpose of
error checking).
Finally, I added a few helper methods to ParserBase to handle a few
classes of expressions (assignments and literals-as-patterns).
Review URL: https://codereview.chromium.org/1696603002
Cr-Commit-Position: refs/heads/master@{#33961}
The path used by that option only comes into play when default parameters
are allowed but destructuring assignment is disallowed. Removing it
allows the removal of one implementation of ParseExpression, and makes
it clearer which code will be dead once all the destructuring flags
are removed.
Also made the |flags| param strongly typed instead of an int.
Review URL: https://codereview.chromium.org/1691653002
Cr-Commit-Position: refs/heads/master@{#33918}
Several minor cleanups to error handling in expression parsing:
- Remove duplication of binding and assignment error reporting.
- RecordBindingPatternError calls are changed to shorter BindingPatternUnexpectedToken
calls where possible.
- No-op error recording calls are removed.
Review URL: https://codereview.chromium.org/1688833004
Cr-Commit-Position: refs/heads/master@{#33915}
Instead of doing a full function body traversal we collect return expressions and mark them after function parsing.
And since we rewrite do-expressions so that the result is explicitly assigned to a result variable the statements marking will never hit so I removed it from the AST.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1693523002
Cr-Commit-Position: refs/heads/master@{#33911}
Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:
Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.
The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.
Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.
R=jarin@chromium.org, rmcilroy@chromium.orgTBR=rossberg@chromium.org
BUG=v8:2159
LOG=n
Review URL: https://codereview.chromium.org/1676883002
Cr-Commit-Position: refs/heads/master@{#33809}
Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.
The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.
This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).
BUG=v8:3699, v8:3761
LOG=n
Review URL: https://codereview.chromium.org/1626423003
Cr-Commit-Position: refs/heads/master@{#33756}
This bit was ostensibly being used to provide appropriate syntax
errors for invalid destructuring assignment patterns, but adding a
single call to RecordPatternError() (in place of
BindingPatternUnexpectedToken()) seems to have replaced the need for it.
Review URL: https://codereview.chromium.org/1665043002
Cr-Commit-Position: refs/heads/master@{#33750}
Also various related cleanup in ParseVariableDeclarations(). The only
changes in logic are explained below:
- We were redundantly checking for parenthesized binding patterns;
these are already ruled out by BindingPatternUnexpectedToken()
calls in the places where we hit an LPAREN.
- There's no need to default-initialize a LET-mode variable in a
for-each loop, just as there isn't for CONST or CONST_LEGACY
(ParseForStatement will take care of properly initializing all
of the above).
Review URL: https://codereview.chromium.org/1661193002
Cr-Commit-Position: refs/heads/master@{#33749}
Note: This is currently only used by yield*, we still need to support it in
other places (such as for-of loops). It can be used manually of course.
(This CL does not touch the full-codegen implementation of yield* because that
code is already dead. The yield* desugaring already supports return and doesn't
need to be touched.)
BUG=v8:3566
LOG=y
Review URL: https://codereview.chromium.org/1639343005
Cr-Commit-Position: refs/heads/master@{#33744}
This CL deals with yield* by desugaring it in the parser. Hence the
full-codegen implementation of it becomes obsolete and can be removed in a
future CL.
The only change in semantics should be that the results of the iterator's next
and throw methods are checked to be objects, which didn't happen before but is
required by the spec.
BUG=
Review URL: https://codereview.chromium.org/1643903003
Cr-Commit-Position: refs/heads/master@{#33735}
This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
This patch adds a UseCounter for each of the following:
- Allowing duplicate sloppy-mode block-scoped function declarations
in the exact same scope
- for-in loops with an initializer
The patch also refactors some of the declaration code to clean it up and
enable the first counter, and adds additional unit tests to nail down
the semantics of edge cases of sloppy-mode block-scoped function declarations.
BUG=v8:4693,chromium:579395
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1633743003
Cr-Commit-Position: refs/heads/master@{#33650}
A class's name is its constructor's name, so there's no need to treat it separately,
either in the parser or in code generation. The main parser use of the name is
for ES2015 Function.name handling, and this patch also cleans up handling there
by adding a new IsAnonymousFunctionDefinition() method to Expression (the name
comes from the spec).
Also removed unused ParserTraits::DefaultConstructor method.
BUG=v8:3699
LOG=n
Review URL: https://codereview.chromium.org/1647213002
Cr-Commit-Position: refs/heads/master@{#33643}
NonPatternRewrite was called more than once for the same AST
in the case of (computed) key expressions present in object
literals. As an example, in:
var x = { [[...42]]: 17 };
the array containing the spread would be desugared first and
then the resulting do-expression would again be desugared.
This could be problematic if a computed key expression contains
large nested array/object literals.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1645023002
Cr-Commit-Position: refs/heads/master@{#33632}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.
BUG=v8:3699, v8:4710
LOG=n
Review URL: https://codereview.chromium.org/1634403002
Cr-Commit-Position: refs/heads/master@{#33562}
In a generator function, the parser rewrites a return statement into a "final"
yield. A final yield used to close the generator, which was incorrect because
the return may occur inside a try-finally clause and so the generator may not
yet terminate.
BUG=
Review URL: https://codereview.chromium.org/1634553002
Cr-Commit-Position: refs/heads/master@{#33537}
ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation
rather than AllowsLazyParsing when deciding whether to parse lazily.
This meant that lexically-scoped variables that had no other referents
wouldn't get closed over properly.
BUG=chromium:580934, v8:4255
LOG=y
Review URL: https://codereview.chromium.org/1630823006
Cr-Commit-Position: refs/heads/master@{#33530}
They were already treated as a BindingPattern error; this patch simply
replaces that call with one marking them as both a binding and assignment
error, and adds parsing tests for both cases.
BUG=v8:4707
LOG=n
Review URL: https://codereview.chromium.org/1632303002
Cr-Commit-Position: refs/heads/master@{#33528}
This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1636013002
Cr-Commit-Position: refs/heads/master@{#33521}
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.
Tail calling can be enabled by --harmony-tailcalls flag.
BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1609893003
Cr-Commit-Position: refs/heads/master@{#33509}
The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).
This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.
BUG=v8:4693, chromium:579395
LOG=y
Review URL: https://codereview.chromium.org/1622723003
Cr-Commit-Position: refs/heads/master@{#33478}
It was not properly rewriting three cases:
- [...[42]][0]
- [...[42]].length
- [...[42]] `foo` (which is a type error)
R=rossberg@chromium.org
BUG=v8:4696
LOG=N
Review URL: https://codereview.chromium.org/1617713002
Cr-Commit-Position: refs/heads/master@{#33433}
Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.
BUG=v8:4692
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1602823003
Cr-Commit-Position: refs/heads/master@{#33420}
Remove an unnecessary is_static argument to ParsePropertyName (the caller
already has easy access to that information) and inline
ParseIdentifierNameOrGetOrSet into its only caller.
Review URL: https://codereview.chromium.org/1606193003
Cr-Commit-Position: refs/heads/master@{#33419}
The old handling of escaped keywords erroneously treated escaped versions
of "let" and "static" as ESCAPED_KEYWORD, leading to erroneous errors in
sloppy mode. Moreover, though the class literal parsing code attempted
to fix up the parsing of escaped versions of "static" to allow it in the
right places, that code wasn't complete.
Fixing the scanner to mark escaped "static" as ESCAPED_STRICT_RESERVED_WORD
allows simplifying the class literal parsing code. A little extra code
was needed to properly handle the new treatment of escaped "let".
Note that "yield" is still broken (that is, we're overly restrictive of
escaped "yield" in sloppy mode).
Review URL: https://codereview.chromium.org/1602013007
Cr-Commit-Position: refs/heads/master@{#33396}
This may have made more sense in the old module design (where
"unification" was a thing), but as-is it's only used for a few
asserts in debug mode. These asserts don't make much sense inside
ModuleDescriptor; instead, as the modules implementation is fleshed
out, I expect the appropriate replacement asserts to show up at the
use of the ModuleDescriptor.
Review URL: https://codereview.chromium.org/1598433006
Cr-Commit-Position: refs/heads/master@{#33345}
This includes anonymous Function, Generator, and Class declarations when
preceded by 'export default'. Parsing only at the moment, nothing useful is
done with the parsed Function/ClassLiteral.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/1589173002
Cr-Commit-Position: refs/heads/master@{#33344}
When derived constructors return a non-object (or not undefined) we
currently throw an exception directly in the callee context. This was
achieved by desugaring the return statement for derived classes. To
be spec compliamnt a separate ConstructStubForDerived is introduced.
Instead of trowing directly, the desugared return statement inside
a derived constructor only returns an integer to indicate an incompatible
result.
BUG=v8:4509
LOG=n
Review URL: https://codereview.chromium.org/1593553002
Cr-Commit-Position: refs/heads/master@{#33336}
This refactoring removes the dependency on the Token class from the
assembler.h header file, the utility function in question has nothing
to do with assembling in the first place.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1594443003
Cr-Commit-Position: refs/heads/master@{#33330}
This avoids manual, fragile assignment to Parser::scope_. And once all such
assignments are removed, BlockState might become much more valuable as
a place to reset scope-related state.
Also remove unnecessary nullptr checks after calls to FinalizeBlockScope.
Review URL: https://codereview.chromium.org/1583453003
Cr-Commit-Position: refs/heads/master@{#33313}
This avoids generating different scopes on the two compilation passes, which
results in various delirious side-effects.
There's some cleanup to be done in lazy arrow function parsing, but I'd
rather do that in a separate patch, with this one targeted at fixing the
particular crash.
BUG=chromium:572589
LOG=n
Review URL: https://codereview.chromium.org/1575333004
Cr-Commit-Position: refs/heads/master@{#33311}
In short, array literals containing spreads, when used as expressions,
are rewritten using do expressions. E.g.
[1, 2, 3, ...x, 4, ...y, 5]
is roughly rewritten as:
do {
$R = [1, 2, 3];
for ($i of x) %AppendElement($R, $i);
%AppendElement($R, 4);
for ($j of y) %AppendElement($R, $j);
%AppendElement($R, 5);
$R
}
where $R, $i and $j are fresh temporary variables.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1564083002
Cr-Commit-Position: refs/heads/master@{#33307}
This patch implements eager expression rewriting when parsing. It will
be used for desugaring spreads but may have other uses in the future.
We call Traits::RewriteExpression as soon as we realise that something
parsed as an expression is actually used as an expression (and not as
a pattern). This patch adds a dummy implementation for this function,
doing no rewriting at all, and adds the trigers in the right places of
the parser.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1567603005
Cr-Commit-Position: refs/heads/master@{#33300}
There's no need to mark these as possibly-direct-eval, since all such an
eval-tagged string will ever get passed is the array of string parts, which
will be immediately returns (since it's not a string). It will
never do a lookup in the current scope, nor (in sloppy mode) introduce
new declarations.
This patch is not intended to change behavior, but I've added tests that
demonstrate the stuff explained in the preceding paragraph.
Review URL: https://codereview.chromium.org/1580463003
Cr-Commit-Position: refs/heads/master@{#33245}
Besides reducing code duplication, this makes it easier to change the
implementation, which may be necessary to properly support eval calls
in arrow function parameter initializers.
Review URL: https://codereview.chromium.org/1573363002
Cr-Commit-Position: refs/heads/master@{#33219}
Removed unused name_ field, made bitfield 16-bits long, and moved it to
the start of the struct, resulting in a reduction of 8 bytes on both
32 and 64-bit platforms.
Most other changes (which prompted this work) are cosmetic:r
- Combined redundant enums
- Named enum values kConsistently
- Consistently use booleans in bitfield, using enum values
only for passing information into NewFunctionLiteral
- Removed unneeded arguments from NewFunctionLiteral, reducing
clutter at callsites
- Added const correctness consistently
Review URL: https://codereview.chromium.org/1566053002
Cr-Commit-Position: refs/heads/master@{#33194}
This patch introduces a mechanism for changing the scope of temporary
variables, which is necessary for rewriting arrow parameter
initializers.
It also fixes a potential bug in AstExpressionVisitor, which did not
visit the automatically generated members of ForEachStatement.
Fixes test/mjsunit/harmony/regress/regress-4658.js
R=rossberg@chromium.org
BUG=v8:4658
LOG=N
Review URL: https://codereview.chromium.org/1564343002
Cr-Commit-Position: refs/heads/master@{#33183}
This required refactoring ParsePropertyDefinition to pass the parsed
string name as an out param, since ObjectLiteralProperty stores Smis
for Smi-representable property keys.
Computed properties are not yet handled in this patch.
BUG=v8:3699
LOG=n
Review URL: https://codereview.chromium.org/1563923002
Cr-Commit-Position: refs/heads/master@{#33141}
We'll be able to optimize rest parameters in TurboFan similarly to the arguments array. This CL restores the previous behavior, and a follow-on will enable TurboFan optimization.
(TBR for rossberg since we discussed the revert beforehand. The only changes are a few lines related to tests and rebasing.)
TBR=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1537683002
Cr-Commit-Position: refs/heads/master@{#33024}
This is behind the --harmony-function-name flag, currently disabled.
With the flag enabled, we now pass the relevant tests in
language/statements/*/fn-name-*.
BUG=v8:3699
LOG=y
Review URL: https://codereview.chromium.org/1518873004
Cr-Commit-Position: refs/heads/master@{#32817}
The %GetPrototype runtime function does a lot more than the
GetSuperConstructor specified in ES6 12.3.5.2. So this introduces a
proper %_GetSuperConstructor instead with support in TurboFan.
R=jarin@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1522503002
Cr-Commit-Position: refs/heads/master@{#32804}
Without this fix, AssignmentExpressions that happen to be arrow functions
would lead to unbalanced Enter/Leave calls on the fni_, causing thrashing
while trying to infer function names. Symptoms include slow parsing
or OOM (when we create too many AstConsStrings).
To try to keep this from happening in the future, added an RAII helper
class to handle Entering/Leaving FNI state.
The included regression test crashes on my workstation without the patch.
Note that it's too slow in debug mode (as well as under TurboFan),
so I've skipped it there.
BUG=v8:4595
LOG=y
Review URL: https://codereview.chromium.org/1507283003
Cr-Commit-Position: refs/heads/master@{#32768}
Attempt #<really big number>
Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time.
Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known
BUG=v8:811
LOG=Y
R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1309813007
Cr-Commit-Position: refs/heads/master@{#32623}
Fix several operations in the parser that rewrite constant expressions
to preserve knowledge regarding whether a value originally contained a ".".
This information is required to accurately validate Asm.js typing.
Making the assumption that if either side of a binary operation contains
a dot, that the rewritten expression should be treated as a double for
Asm.js purposes. This is a slight deviation from the spec (which
would forbid mix type operations).
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator, test-parsing
R=titzer@chromium.org,marja@chromium.org,aseemgarg@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1492123002
Cr-Commit-Position: refs/heads/master@{#32581}
Both the is_const and declaration_scope fields can be reliably derived
from the mode field. needs_init cannot be, unfortunately, due to the
special case of CONST in for loops.
Also inline the sole remaining non-trivial caller of
Parser::DeclarationScope(VariableMode).
Review URL: https://codereview.chromium.org/1487603003
Cr-Commit-Position: refs/heads/master@{#32536}
This hackily disambiguates multiple calls for the iterator protocols in ForOf / Yield* by adding -2 / -1 to the pos.
BUG=v8:3953
LOG=y
Review URL: https://codereview.chromium.org/1491923003
Cr-Commit-Position: refs/heads/master@{#32527}
This fixes a corner-case in redeclaration handling, where the ES2015
early error case got mixed up with legacy const handling in the parser.
Redeclaration using ES2015 'let' and 'const' should be early errors,
but legacy 'const' redeclaration has historically been a runtime error,
and should stay that way until legacy 'const' is gone.
The fix here is uglier than it might be due to
https://code.google.com/p/v8/issues/detail?id=4577, which keeps us
from simplifying the mess of if/else-if in the current code.
BUG=v8:4576
LOG=n
Review URL: https://codereview.chromium.org/1485943002
Cr-Commit-Position: refs/heads/master@{#32429}
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
