Skip to content

V
V8
Switch branch/tag
  1. 08 Apr, 2016 2 commits
  3. 01 Apr, 2016 1 commit
  5. 24 Mar, 2016 2 commits
  7. 22 Mar, 2016 1 commit
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored 
      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}
      ed18aa65
  9. 21 Mar, 2016 1 commit
    • vogelheim's avatar
      Revert of Parser: Make skipping HTML comments optional. (patchset #6 id:140001... · 09ac4f29
      vogelheim authored 
      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}
      09ac4f29
  11. 18 Mar, 2016 2 commits
  13. 16 Mar, 2016 1 commit
  15. 15 Mar, 2016 1 commit
    • adamk's avatar
      Remove --harmony-modules flag and let embedder decide when modules are used · 5a202cce
      adamk authored 
      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}
      5a202cce
  17. 10 Mar, 2016 2 commits
  19. 08 Mar, 2016 1 commit
  21. 03 Mar, 2016 1 commit
    • littledan's avatar
      Restrict FunctionDeclarations in Statement position · 0e7f095c
      littledan authored 
      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}
      0e7f095c
  23. 01 Mar, 2016 1 commit
  25. 18 Feb, 2016 1 commit
  27. 17 Feb, 2016 1 commit
  29. 16 Feb, 2016 1 commit
  31. 12 Feb, 2016 1 commit
    • adamk's avatar
      Remove AssignmentExpressionFlags enum, handle error checking in callers · 1003785c
      adamk authored 
      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}
      1003785c
  33. 02 Feb, 2016 1 commit
  35. 26 Jan, 2016 1 commit
  37. 20 Jan, 2016 1 commit
  39. 19 Jan, 2016 1 commit
    • adamk's avatar
      Fix handling of escaped "let" and "static" tokens · c04ef1ff
      adamk authored 
      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}
      c04ef1ff
  41. 15 Jan, 2016 1 commit
  43. 14 Jan, 2016 1 commit
  45. 13 Jan, 2016 1 commit
  47. 11 Jan, 2016 1 commit
    • littledan's avatar
      Ship ES2015 sloppy-mode const semantics · 95145fa8
      littledan authored 
      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}
      95145fa8
  49. 08 Jan, 2016 3 commits
  51. 16 Dec, 2015 1 commit
  53. 12 Dec, 2015 1 commit
  55. 11 Dec, 2015 3 commits
  57. 09 Dec, 2015 1 commit
  59. 07 Dec, 2015 1 commit
  61. 04 Dec, 2015 1 commit
    • caitpotter88's avatar
      [es6] implement destructuring assignment · b634a61d
      caitpotter88 authored 
      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}
      b634a61d
  63. 03 Dec, 2015 1 commit
    • bradnelson's avatar
      Preserve information about dots in numbers across parser rewriting. · 1e4681c3
      bradnelson authored 
      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}
      1e4681c3