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