Skip to content

V
V8
Switch branch/tag
  1. 19 Feb, 2016 4 commits
    • nikolaos's avatar
      This patch implements an alternative approach to the rewriting · ed665880
      nikolaos authored 
      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}
      ed665880
    • machenbach's avatar
      Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of... · 5bb6b47b
      machenbach authored 
      Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of https://codereview.chromium.org/1702063002/ )

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}
      5bb6b47b
    • nikolaos's avatar
      This patch implements an alternative approach to the rewriting · 7f5c864a
      nikolaos authored 
      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}
      7f5c864a
    • adamk's avatar
      Don't reflect ES2015 Function name inference in Function.prototype.toString · cc2ea257
      adamk authored 
      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}
      cc2ea257
  3. 04 Feb, 2016 2 commits
  5. 20 Jan, 2016 1 commit
  7. 08 Jan, 2016 2 commits
    • adamk's avatar
      Clean up FunctionLiteral AST node cruft · 316dc173
      adamk authored 
      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}
      316dc173
    • caitpotter88's avatar
      [parser] parenthesized Literals are not valid AssignmentPatterns · 1f1af42d
      caitpotter88 authored 
      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}
      1f1af42d
  9. 06 Jan, 2016 1 commit
  11. 11 Dec, 2015 3 commits
  13. 07 Dec, 2015 1 commit
  15. 26 Nov, 2015 1 commit
  17. 25 Nov, 2015 1 commit
    • adamk's avatar
      Disallow destructuring in legacy sloppy for-in loop parsing · ceb92ebf
      adamk authored 
      For web compat reasons, we support an initializer in the declaration
part of a for-in loop. But we should disallow this for destructured
declarations (just as we do for lexical declarations). In fact, without
disallowing it, we crash.

Also fix up the PreParser to have the same restrictions here as the parser
(the lexical check was missing there), verified by running the message tests
with --min-preparse-length=0.

In fixing the logic I've also cleaned up the code a bit, removing the
only-called-once DeclarationParsingResult::SingleName method.

BUG=v8:811
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32236}
      ceb92ebf
  19. 18 Nov, 2015 1 commit
  21. 12 Nov, 2015 1 commit
    • adamk's avatar
      [cleanup] Remove un-scoped ParseBlock from Parser · b0b97da5
      adamk authored 
      Because the Scope will be optimized away by the call to
FinalizeBlockScope in the case where there are no lexical
declarations in the block, this should have no effect on
anything downstream from the Parser, and simply removes
duplicate parsing code.

Due to the change from ParseStatement to ParseStatementListItem,
this will result in slightly different error messages for
lexical declarations in sloppy mode (until those are shipped).

R=littledan@chromium.org, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

Cr-Commit-Position: refs/heads/master@{#31966}
      b0b97da5
  23. 05 Nov, 2015 4 commits
  25. 04 Nov, 2015 3 commits
  27. 21 Oct, 2015 1 commit
  29. 07 Oct, 2015 1 commit
    • adamk's avatar
      Use Scope::function_kind_ to distinguish arrow function scopes · 24565b85
      adamk authored 
      Previously, arrow function scopes had a separate ScopeType. However,
Scope::DeserializeScopeChain() erroneously deserialized ARROW_SCOPE
ScopeInfos as FUNCTION_SCOPE. This could lead to bugs such as the
attached one, where "super" was disallowed where it should have
been allowed.

This patch utilizes the Scope's FunctionKind to distinguish arrow
functions from others. Besides fixing the above bug, this also
simplifies code in various places that had to deal with two different
ScopeTypes both of which meant "function".

BUG=v8:4466
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31154}
      24565b85
  31. 05 Oct, 2015 1 commit
    • littledan's avatar
      Prohibit let in lexical bindings · 7e113c47
      littledan authored 
      This patch prohibits lexical bindings from being called 'let', even in
sloppy mode, following the ES2015 specification. The change affects
multiple cases of lexical bindings, including simple let/const declarations
and both kinds of for loops. var and legacy const bindings still permit
the name to be let, including in destructuring cases. Tests are added to
verify, though some cases are commented out since they led to (pre-existing)
crashes.

BUG=v8:4403
R=adamk
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#31115}
      7e113c47
  33. 30 Sep, 2015 1 commit
  35. 28 Sep, 2015 1 commit
  37. 24 Sep, 2015 3 commits
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8fe3ac07
      bmeurer authored 
      There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4413, v8:4430
LOG=n

Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
Cr-Commit-Position: refs/heads/master@{#30900}

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

Cr-Commit-Position: refs/heads/master@{#30902}
      8fe3ac07
    • bmeurer's avatar
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001... · 656ebdce
      bmeurer authored 
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )

Reason for revert:
Failed on Fuzzer and MIPS bot.

Original issue's description:
> [es6] Introduce spec compliant IsConstructor.
>
> There was already a bit on the Map named "function with prototype",
> which basically meant that the Map was a map for a JSFunction that could
> be used as a constructor. Now this CL generalizes that bit to
> IsConstructor, which says that whatever (Heap)Object you are looking at
> can be used as a constructor (i.e. the bit is also set for bound
> functions that can be used as constructors and proxies that have a
> [[Construct]] internal method).
>
> This way we have a single chokepoint for IsConstructor checking, which
> allows us to get rid of the various ways in which we tried to guess
> whether something could be used as a constructor or not.
>
> Drive-by-fix: Renamed IsConstructor on FunctionKind to
> IsClassConstructor to resolve the weird name clash, and the
> IsClassConstructor name also matches the spec.
>
> R=jarin@chromium.org, rossberg@chromium.org
> BUG=v8:4430
> LOG=n
>
> Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
> Cr-Commit-Position: refs/heads/master@{#30900}

TBR=jarin@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4430

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

Cr-Commit-Position: refs/heads/master@{#30901}
      656ebdce
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8de4d935
      bmeurer authored 
      There was already a bit on the Map named "function with prototype",
which basically meant that the Map was a map for a JSFunction that could
be used as a constructor. Now this CL generalizes that bit to
IsConstructor, which says that whatever (Heap)Object you are looking at
can be used as a constructor (i.e. the bit is also set for bound
functions that can be used as constructors and proxies that have a
[[Construct]] internal method).

This way we have a single chokepoint for IsConstructor checking, which
allows us to get rid of the various ways in which we tried to guess
whether something could be used as a constructor or not.

Drive-by-fix: Renamed IsConstructor on FunctionKind to
IsClassConstructor to resolve the weird name clash, and the
IsClassConstructor name also matches the spec.

R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4430
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#30900}
      8de4d935
  39. 18 Sep, 2015 1 commit
  41. 01 Sep, 2015 1 commit
  43. 28 Aug, 2015 1 commit
    • littledan's avatar
      Sloppy-mode let parsing · decc7b09
      littledan authored 
      This patch makes 'let' a contextual keyword in both strict and sloppy mode.
It behaves as a keyword when used at the beginning of a StatementListItem
or lexical declaration at the beginning of a for statement, if it is followed
by an identifier, [ or {. Implementing this change requires an extra token
look-ahead by the parser which is only invoked in certain cases (so as to
avoid parsing RegExps as ECMAScript tokens). This might result in a slowdown
of the scanner, but performance testing of this patch hasn't yet found much
of a regression.

BUG=v8:3305
LOG=Y
R=adamk,vogelheim

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

Cr-Commit-Position: refs/heads/master@{#30451}
      decc7b09
  45. 26 Aug, 2015 1 commit
  47. 15 Aug, 2015 1 commit
    • caitpotter88's avatar
      [parser] make kInvalidLhsInFor a SyntaxError · 9b15445e
      caitpotter88 authored 
      Second item in section 13.7.5.1 states that the error should be a
SyntaxError, when previously CheckAndRewriteReferenceExpression
would always emit a ReferenceError.

BUG=v8:4373
R=adamk, rossberg
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

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

Cr-Commit-Position: refs/heads/master@{#30184}
      9b15445e
  49. 13 Aug, 2015 2 commits