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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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 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}
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}
