Commit Graph

455 Commits

Author SHA1 Message Date
jwolfe
1ac0965542 Allow trailing commas in function parameter lists
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}
2016-06-29 01:39:10 +00:00
caitpotter88
4efd20ab57 [parser] report error for shorthand property "await" in async arrow formals
In addition to recording the BindingPattern error, also record an
AsyncArrowFormalParameters error for shorthand property "await" in object
literals.

BUG=v8:4483, v8:5148
R=littledan@chromium.org, jwolfe@igalia.com, adamk@chromium.org, nikolaos@chromium.org

Review-Url: https://codereview.chromium.org/2100623002
Cr-Commit-Position: refs/heads/master@{#37302}
2016-06-27 21:12:19 +00:00
caitpotter88
4bb1f70e66 [parser] don't report error for CoverInitializedNames in async arrow formals
BUG=v8:4483, v8:5148
R=littledan@chromium.org, adamk@chromium.org, jwolfe@igalia.com, nikolaos@chromium.org

Review-Url: https://codereview.chromium.org/2091313002
Cr-Commit-Position: refs/heads/master@{#37260}
2016-06-25 00:39:11 +00:00
caitpotter88
e45fba811f [parser] only parse async arrow function when necessary
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}
2016-06-21 19:48:15 +00:00
oleksandr.chekhovskyi
2f6be682ac Parser: Report use counts once per feature
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}
2016-06-14 21:41:31 +00:00
littledan
6390282f96 Improve strictness of Annex B 3.3 for generators and async functions
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}
2016-05-27 18:23:20 +00:00
mike
d0c65f93bf [parser] Relex restriction on reserved words
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}
2016-05-17 21:14:01 +00:00
caitpotter88
0d43421a22 [esnext] implement frontend changes for async/await proposal
BUG=v8:4483
LOG=Y
R=littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/1841543003
Cr-Commit-Position: refs/heads/master@{#36261}
2016-05-16 23:19:02 +00:00
adamk
0783a6fc27 Further expand parsing tests around yield in generator/arrow parameters
No bugs found, but the additional coverage of arrows as default param
initializers in a generator param list seems good to have.

R=littledan@chromium.org

Review-Url: https://codereview.chromium.org/1949293002
Cr-Commit-Position: refs/heads/master@{#36089}
2016-05-06 19:31:50 +00:00
adamk
40b3626e45 Disallow yield in computed property names of class expressions in params
R=littledan@chromium.org
BUG=v8:4974
LOG=n

Review-Url: https://codereview.chromium.org/1949223002
Cr-Commit-Position: refs/heads/master@{#36047}
2016-05-04 23:25:25 +00:00
nikolaos
0d1687b9df Add support for disabling the preparser when testing modules
R=adamk@chromium.org
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/1952473003
Cr-Commit-Position: refs/heads/master@{#36035}
2016-05-04 17:22:20 +00:00
adamk
9e9abcfff4 Properly disallow 'yield' in class expressions and arrow parameters
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}
2016-05-03 01:57:48 +00:00
mike
efe5b72d02 [parser] Enforce module-specific identifier restriction
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}
2016-04-29 18:14:48 +00:00
adamk
f1a0f054fb Several tiny cleanups in test-parsing.cc
R=littledan@chromium.org

Review-Url: https://codereview.chromium.org/1926133003
Cr-Commit-Position: refs/heads/master@{#35890}
2016-04-29 06:44:18 +00:00
littledan
63b935428c Disallow generator declarations in certain locations
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}
2016-04-27 19:18:38 +00:00
adamk
967a04634d Forward accept_IN to ParseYieldExpression
This allows "yield 'x' in o" as an expression in a generator.

R=ishell@chromium.org
BUG=v8:4945
LOG=n

Review URL: https://codereview.chromium.org/1916183003

Cr-Commit-Position: refs/heads/master@{#35798}
2016-04-26 17:24:49 +00:00
adamk
739947880c Widen --harmony-for-in flag to throw errors in PreParser
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}
2016-04-26 00:29:50 +00:00
mike
b86ec74395 [modules] Infer strict mode from within scope object
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}
2016-04-22 13:38:15 +00:00
mike
43fa3e65c9 [modules] Treat top-level functions as lexical
[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}
2016-04-19 17:53:03 +00:00
mstarzinger
1407c89427 [parser] Remove ParseInfo::closure field.
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}
2016-04-08 12:32:23 +00:00
adamk
a0a8ecd078 Remove runtime flags for sloppy mode block scoping features
These were all on by default in M49 without complaint.

R=littledan@chromium.org

Review URL: https://codereview.chromium.org/1858943002

Cr-Commit-Position: refs/heads/master@{#35342}
2016-04-08 00:30:20 +00:00
jochen
cb7aa79b12 Expose a lower bound of malloc'd memory via heap statistics
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}
2016-04-01 10:01:56 +00:00
rmcilroy
838cea4e4e [Interpreter] Make ignition compiler eagerly.
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1811553003

Cr-Commit-Position: refs/heads/master@{#35066}
2016-03-24 18:38:24 +00:00
littledan
7f108b655b Implement ES2015 labelled function declaration restrictions
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}
2016-03-24 01:59:47 +00:00
adamk
ed18aa65ea Remove support for legacy const, part 1
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}
2016-03-22 17:52:13 +00:00
vogelheim
09ac4f295c Revert of Parser: Make skipping HTML comments optional. (patchset #6 id:140001 of https://codereview.chromium.org/1801203002/ )
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}
2016-03-21 17:50:22 +00:00
vogelheim
91d344288a 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

Review URL: https://codereview.chromium.org/1801203002

Cr-Commit-Position: refs/heads/master@{#34904}
2016-03-18 17:24:19 +00:00
caitpotter88
17c92fe6bb [es7] implement exponentiation operator proposal
Implements Stage 4 proposal from http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=Y
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1678303002

Cr-Commit-Position: refs/heads/master@{#34890}
2016-03-18 13:54:05 +00:00
caitpotter88
14188ea07f [parser] report illegal token error in ParseMemberExpressionContinuation()
Report correct error message when a scanner error occurs while parsing a tagged
template within an expression context.

BUG=v8:4829, v8:3230
LOG=N
R=adamk@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1806063002

Cr-Commit-Position: refs/heads/master@{#34839}
2016-03-16 20:26:00 +00:00
adamk
5a202cce6e Remove --harmony-modules flag and let embedder decide when modules are used
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}
2016-03-15 00:45:00 +00:00
adamk
dea9559457 Remove destructuring and default arguments runtime flags
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}
2016-03-10 23:22:30 +00:00
rossberg
4614c7caaf [strong] Remove all remainders of strong mode
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

Review URL: https://codereview.chromium.org/1773653002

Cr-Commit-Position: refs/heads/master@{#34669}
2016-03-10 12:45:42 +00:00
verwaest
7736102034 Add GetProperty/GetElement to JSReceiver and use it where possible
Also move GetProperty with string-name to JSReceiver

BUG=

Review URL: https://codereview.chromium.org/1775973002

Cr-Commit-Position: refs/heads/master@{#34596}
2016-03-08 17:30:42 +00:00
littledan
0e7f095c6d Restrict FunctionDeclarations in Statement position
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}
2016-03-03 21:34:26 +00:00
nikolaos
86a9ef31c7 Fix bug with multiple directives in the preparser
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}
2016-03-01 13:59:08 +00:00
adamk
63efda35b3 Remove strong mode support from Scope and Variable
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}
2016-02-18 17:20:13 +00:00
caitpotter88
3649170259 [cleanup] add Parser accessors for FLAG_harmony_function_sent
BUG=
LOG=N
R=adamk@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1702853002

Cr-Commit-Position: refs/heads/master@{#34051}
2016-02-17 00:19:21 +00:00
caitpotter88
fd2edb0ea2 [parser] unify metaproperty parsing and require unescaped property name
BUG=v8:4756
LOG=N
R=adamk@chromium.org, littledan@chromium.org, wingo@igalia.com

Review URL: https://codereview.chromium.org/1700123003

Cr-Commit-Position: refs/heads/master@{#34050}
2016-02-16 23:38:09 +00:00
adamk
1003785ced Remove AssignmentExpressionFlags enum, handle error checking in callers
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}
2016-02-12 22:38:46 +00:00
caitpotter88
15da984326 [parser] report invalid rest parameter errors in Arrow functions
Based on vogelheim's CL at https://codereview.chromium.org/1657783002/

BUG=chromium:582626, v8:2700
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, vogelheim@chromium.org

Review URL: https://codereview.chromium.org/1656993002

Cr-Commit-Position: refs/heads/master@{#33651}
2016-02-02 00:33:07 +00:00
adamk
b874e3d521 Treat yield expressions as an AssignmentPattern error
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}
2016-01-26 21:15:53 +00:00
mike
f7263b6a3f [parser] Disallow Expression in for..of statements
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}
2016-01-20 22:05:48 +00:00
adamk
c04ef1ffcb Fix handling of escaped "let" and "static" tokens
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}
2016-01-19 21:24:59 +00:00
adamk
25532be593 [modules] Support parsing anonymous default exports
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}
2016-01-15 20:39:00 +00:00
caitpotter88
d19e3a21d6 [parser] reject AssignmentElements with non-ASSIGN initializer ops
When parsing a pattern element with an assignment operator that is not
Token::ASSIGN, record a pattern error to indicate the invalid assignment target.

BUG=v8:811, v8:4666
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1583863003

Cr-Commit-Position: refs/heads/master@{#33279}
2016-01-14 03:09:16 +00:00
caitpotter88
6b28f294c1 [parser] reject parenthesized patterns as DestructuringAssignmentTargets
http://tc39.github.io/ecma262/#sec-destructuring-assignment-static-semantics-early-errors
requires that DestructuringAssignmentTargets which do not match Pattern productions,
must return true for IsValidSimpleAssignmentTarget.

This change rejects parenthesized patterns with a SyntaxError.

BUG=v8:4662, v8:811
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, nikolaos@chromium.org

Review URL: https://codereview.chromium.org/1585473002

Cr-Commit-Position: refs/heads/master@{#33254}
2016-01-13 00:41:16 +00:00
littledan
95145fa826 Ship ES2015 sloppy-mode const semantics
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.

R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1571873004

Cr-Commit-Position: refs/heads/master@{#33218}
2016-01-11 23:09:59 +00:00
caitpotter88
dfce900d64 [es6] enable destructuring rest parameters
Originally, only BindingIdentifiers were a legal operand for the `...` ellipsis
in a function rest parameter. This has since changed, allowing the rest array
to be destructured.

The grammar is now the following:

```
FunctionRestParameter[Yield]:
    BindingRestElement[?Yield]

BindingRestElement[Yield]:
    ... BindingIdentifier[?Yield]
    ... BindingPattern[?Yield]
```

*Spec change: d322357e6b
*TC39 Discussion: https://github.com/tc39/tc39-notes/blob/master/es7/2015-07/july-28.md#66-bindingrestelement-should-allow-a-bindingpattern-ala-assignmentrestelement

BUG=v8:4627, v8:2159
LOG=N
R=littledan@chromium.org, adamk@chromium.org, wingo@igalia.com, rossberg@chromium.org

Review URL: https://codereview.chromium.org/1532873004

Cr-Commit-Position: refs/heads/master@{#33192}
2016-01-08 20:22:52 +00:00
caitpotter88
1f1af42d3a [parser] parenthesized Literals are not valid AssignmentPatterns
Encode "parenthesized" status of parenthesized Expressions to prevent
them from being treated as Patterns.

BUG=v8:4657, v8:811
LOG=N
R=rossberg@chromium.org, adamk@chromium.org, littledan@chromium.org

Review URL: https://codereview.chromium.org/1570793002

Cr-Commit-Position: refs/heads/master@{#33190}
2016-01-08 17:47:17 +00:00
littledan
eb9deba815 Fix sloppy block-scoped function hoisting with nested zones
The sloppy block-scoped function declaration placeholder statements
are held in parser_zone_-allocated hashtables. These hashtables are
not updated when local_zone_s are removed. Therefore, the
NewSloppyBlockFunctionStatement method should allocate
SloppyBlockScopeFunctionStatements in the parser_zone_ to avoid a
use-after-free. Scope fixup code may end up updating something which
is thrown away, but this is a small cost and much simpler than
removing dead hashtable entries later.

R=adamk
LOG=Y
BUG=chromium:537816

Review URL: https://codereview.chromium.org/1564923007

Cr-Commit-Position: refs/heads/master@{#33185}
2016-01-08 16:16:46 +00:00