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}
