1. 09 Nov, 2015 1 commit
  2. 05 Nov, 2015 2 commits
    • adamk's avatar
      [cleanup] Make control flow in ParsePrimaryExpression more consistent · 1447f743
      adamk authored
      The previous code had a mix of breaks, early returns, and switch/case/if
      with fallthrough. Now the pattern is to either return for known errors
      or break to the bottom of the switch for unhandled tokens.
      
      Also cleaned up random other stuff in the function: removed unnecessary
      local vars, shortened position-fetching calls.
      
      Review URL: https://codereview.chromium.org/1412313009
      
      Cr-Commit-Position: refs/heads/master@{#31843}
      1447f743
    • caitpotter88's avatar
      [es6] allow any LeftHandSideExpression in for-of loops · 096125de
      caitpotter88 authored
      Fix an earlier regression which forbid non-VariableProxy LHS from being
      used in for-of loops. Like for-in loops, the spec allows any LHS to be used,
      with the sole exception that ObjectLiterals and ArrayLiterals must be valid
      AssignmentPatterns.
      
      Also fixes a bug in TurboFan which resulted in incorrectly replacing a variable load with a constant value in some instances, due to the AstLoopAssignmentAnalyzer failing to record the assignment to ForOfStatement's value.
      
      BUG=v8:4418, v8:2720
      LOG=N
      R=wingo@igalia.com, littledan@chromium.org, adamk@chromium.org, bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1411873004
      
      Cr-Commit-Position: refs/heads/master@{#31816}
      096125de
  3. 04 Nov, 2015 1 commit
  4. 29 Oct, 2015 1 commit
    • adamk's avatar
      Fix eval calls in initializers of arrow function parameters · 0bdaa4d8
      adamk authored
      This requires copying usage flags from the outer scope to the
      arrow scope upon encountering the arrow token.
      
      In order to properly pass-on the calls_eval bit, now record
      that bit on script scopes just like everywhere else, and add
      necessary code to scopes.cc to handle that change in behavior.
      
      Also factored out scope flag propagation to its own method to
      make the call site simple (though note that only the eval
      bit makes any difference for arrows).
      
      BUG=v8:4395
      LOG=n
      
      Review URL: https://codereview.chromium.org/1423613002
      
      Cr-Commit-Position: refs/heads/master@{#31660}
      0bdaa4d8
  5. 28 Oct, 2015 2 commits
  6. 21 Oct, 2015 1 commit
  7. 20 Oct, 2015 2 commits
    • bmeurer's avatar
      Revert of [es6] Fix scoping for default parameters in arrow functions... · e41614a0
      bmeurer authored
      Revert of [es6] Fix scoping for default parameters in arrow functions (patchset #5 id:80001 of https://codereview.chromium.org/1405313002/ )
      
      Reason for revert:
      Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/2407/steps/Check/logs/regress-4395
      
      Original issue's description:
      > [es6] Fix scoping for default parameters in arrow functions
      >
      > When eagerly parsing arrow functions, expressions in default
      > parameter initializers are parsed in the enclosing scope,
      > rather than in the function's scope (since that scope does not
      > yet exist). This leads to VariableProxies being added to the
      > wrong scope, and scope chains for FunctionLiterals being incorrect.
      >
      > This patch addresses these problems by adding a subclass of
      > AstExpressionVisitor that moves VariableProxies to the proper
      > scope and fixes up scope chains of FunctionLiterals.
      >
      > More work likely still needs to be done to make this work completely,
      > but it's very close to correct.
      >
      > BUG=v8:4395
      > LOG=y
      >
      > Committed: https://crrev.com/cf72aad39e51de9b7074ea039377c1812f4a2c6b
      > Cr-Commit-Position: refs/heads/master@{#31402}
      
      TBR=rossberg@chromium.org,caitpotter88@gmail.com,adamk@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4395
      
      Review URL: https://codereview.chromium.org/1417463004
      
      Cr-Commit-Position: refs/heads/master@{#31404}
      e41614a0
    • adamk's avatar
      [es6] Fix scoping for default parameters in arrow functions · cf72aad3
      adamk authored
      When eagerly parsing arrow functions, expressions in default
      parameter initializers are parsed in the enclosing scope,
      rather than in the function's scope (since that scope does not
      yet exist). This leads to VariableProxies being added to the
      wrong scope, and scope chains for FunctionLiterals being incorrect.
      
      This patch addresses these problems by adding a subclass of
      AstExpressionVisitor that moves VariableProxies to the proper
      scope and fixes up scope chains of FunctionLiterals.
      
      More work likely still needs to be done to make this work completely,
      but it's very close to correct.
      
      BUG=v8:4395
      LOG=y
      
      Review URL: https://codereview.chromium.org/1405313002
      
      Cr-Commit-Position: refs/heads/master@{#31402}
      cf72aad3
  8. 15 Oct, 2015 1 commit
  9. 14 Oct, 2015 1 commit
  10. 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
  11. 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
  12. 30 Sep, 2015 2 commits
  13. 28 Sep, 2015 1 commit
  14. 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
  15. 16 Sep, 2015 2 commits
  16. 02 Sep, 2015 1 commit
  17. 28 Aug, 2015 2 commits
    • 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
    • wingo's avatar
      Disallow yield in default parameter initializers · a9d24d3f
      wingo authored
      R=adamk@chromium.org
      LOG=N
      BUG=v8:4397
      
      Review URL: https://codereview.chromium.org/1320673007
      
      Cr-Commit-Position: refs/heads/master@{#30431}
      a9d24d3f
  18. 26 Aug, 2015 3 commits
  19. 24 Aug, 2015 1 commit
    • yangguo's avatar
      Revert of Parse arrow functions at proper precedence level (patchset #2... · cc97e524
      yangguo authored
      Revert of Parse arrow functions at proper precedence level (patchset #2 id:60001 of https://codereview.chromium.org/1286383005/ )
      
      Reason for revert:
      Breaks layout test. Please change test expectation on blink first.
      
      --- /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-expected.txt
      +++ /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-actual.txt
      @@ -1,4 +1,4 @@
      -CONSOLE ERROR: line 9: Uncaught SyntaxError: Expected () to start arrow function, but got '}' instead of '=>'
      +CONSOLE ERROR: line 9: Uncaught SyntaxError: Unexpected token )
       Tests that pause on exception in internal script does not crash.
      
       Script source was shown.
      
      Original issue's description:
      > Parse arrow functions at proper precedence level
      >
      > BUG=v8:4211
      > LOG=Y
      > R=rossberg@chromium.org
      >
      > Committed: https://crrev.com/9271b0ccf9ddb217deb1f0b9ef9b59b64dc40214
      > Cr-Commit-Position: refs/heads/master@{#30298}
      
      TBR=rossberg@chromium.org,mstarzinger@chromium.org,fennyfanny655@gmail.com,machenbach@chromium.org,wingo@igalia.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4211
      
      Review URL: https://codereview.chromium.org/1315503002
      
      Cr-Commit-Position: refs/heads/master@{#30318}
      cc97e524
  20. 21 Aug, 2015 2 commits
  21. 17 Aug, 2015 1 commit
  22. 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
  23. 13 Aug, 2015 2 commits
  24. 12 Aug, 2015 1 commit
    • littledan's avatar
      Split function block scoping into a separate flag · 1ebf0d7c
      littledan authored
      In an initial attempt to implement sloppy mode lexical bindings,
      functions were made lexically scoped in sloppy mode. However, the
      ES2015 spec says that they need an additional hoisted var binding,
      and further, it's not clear when we'll implement that behavior
      or whether it's web-compatible.
      
      This patch splits off function block scoping into a new, separate
      flag called --harmony_sloppy_function. This change will enable the
      possibility of testing and shipping this feature separately from
      other block scoping-related features which don't have the same risks.
      
      BUG=v8:4285
      R=adamk
      LOG=N
      
      Review URL: https://codereview.chromium.org/1282093002
      
      Cr-Commit-Position: refs/heads/master@{#30122}
      1ebf0d7c
  25. 11 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove several grab-bag includes from the v8.h header. · 58109a2c
      mstarzinger authored
      This is the first step of turning the v8.h file into a normal header
      instead of an include-the-world header. The new rule is that no other
      header files are allowed to include v8.h, which is enforced by DEPS.
      
      Also the number of includes inside the v8.h file has been drastically
      reduced. Basically the last missing piece is the inclusion of the big
      objects-inl.h file.
      
      This in turn makes many headers follow the IWYU principle.
      
      R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1282503003
      
      Cr-Commit-Position: refs/heads/master@{#30102}
      58109a2c
  26. 07 Aug, 2015 1 commit
  27. 05 Aug, 2015 2 commits