1. 20 May, 2016 1 commit
  2. 10 May, 2016 1 commit
  3. 09 May, 2016 1 commit
  4. 04 May, 2016 1 commit
    • ishell's avatar
      [es8] More spec compliant syntactic tail calls implementation. · 1350eb3d
      ishell authored
      Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
      
      --harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
      
      This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
      
      BUG=v8:4915
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1928203002
      Cr-Commit-Position: refs/heads/master@{#36024}
      1350eb3d
  5. 03 May, 2016 1 commit
    • adamk's avatar
      Properly disallow 'yield' in class expressions and arrow parameters · 9e9abcff
      adamk authored
      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}
      9e9abcff
  6. 29 Apr, 2016 1 commit
  7. 27 Apr, 2016 1 commit
  8. 26 Apr, 2016 1 commit
  9. 08 Apr, 2016 1 commit
  10. 04 Apr, 2016 2 commits
    • yangguo's avatar
      [interpreter] add some expression positions. · f7e7ba11
      yangguo authored
      Statement positions should overwrite expression positions if they
      have the same bytecode offset.
      
      R=mstarzinger@chromium.org, vogelheim@chromium.org
      BUG=v8:4680,v8:4689
      LOG=N
      
      Review URL: https://codereview.chromium.org/1855913002
      
      Cr-Commit-Position: refs/heads/master@{#35236}
      f7e7ba11
    • neis's avatar
      Preserve exception message in iterator finalization. · f70b3d3b
      neis authored
      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}
      f70b3d3b
  11. 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
  12. 21 Mar, 2016 2 commits
  13. 18 Mar, 2016 2 commits
  14. 16 Mar, 2016 1 commit
  15. 14 Mar, 2016 2 commits
    • littledan's avatar
      Make test262 test runner check for which exception is thrown · f3568ca4
      littledan authored
      test262 "negative" test expectations list which exception is thrown. The ES2017
      draft specification is very specific about which exception class is thrown
      from which path, and V8 works hard to be correct with respect to that spec.
      
      Previously, the test262 test runner would accept any nonzero status code,
      such as from a crash, or a FAIL printed out, for a negative test. This
      patch makes negative tests check for the right answer using a quick-and-dirty
      parsing of the exception printing from d8 to find the exception class.
      It invokes d8 in a way to get a status code of 0 from thrown exceptions
      so that 'negative' tests aren't actually implemented by negating the output.
      
      Amazingly, this didn't catch any test262 failures, but I verified the extra
      checking interactively by changing a negative test to expect a different type
      and saw it fail.
      
      BUG=v8:4803
      R=machenbach
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1766503002
      
      Cr-Commit-Position: refs/heads/master@{#34763}
      f3568ca4
    • mstarzinger's avatar
      [testing] Move the last JS tests out of "preparser". · a02b7aaa
      mstarzinger authored
      This moves the last remaining JS file based tests out of the "preparser"
      suite. The tests in question all are expected to parse normally and not
      throw any exception. This also deprecates the ability of the test suite
      to run anything else outside Python templated tests.
      
      R=adamk@chromium.org
      TEST=preparser
      
      Review URL: https://codereview.chromium.org/1782173005
      
      Cr-Commit-Position: refs/heads/master@{#34753}
      a02b7aaa
  16. 11 Mar, 2016 3 commits
  17. 10 Mar, 2016 1 commit
  18. 26 Feb, 2016 1 commit
  19. 16 Feb, 2016 2 commits
  20. 02 Feb, 2016 1 commit
  21. 08 Jan, 2016 1 commit
    • littledan's avatar
      Reland of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #1... · 23235b5f
      littledan authored
      Reland of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #1 id:1 of https://codereview.chromium.org/1565263002/ )
      
      Reason for revert:
      Crash fixed by https://codereview.chromium.org/1564923007
      
      Original issue's description:
      > Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
      >
      > Reason for revert:
      > Causes frequent crashes in Canary: chromium:537816
      >
      > Original issue's description:
      > > Ship ES2015 sloppy-mode function hoisting, let, class
      > >
      > > This patch doesn't ship all features of ES2015 variable/scoping
      > > changes, notably omitting the removal of legacy const. I think
      > > function hoisting, let and class in sloppy mode can stand to
      > > themselves as a package, and the legacy const change is much
      > > riskier and more likely to be reverted, so my intention is to
      > > pursue those as a separate, follow-on patch.
      > >
      > > R=adamk@chromium.org
      > > BUG=v8:4285,v8:3305
      > > LOG=Y
      > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > >
      > > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
      > > Cr-Commit-Position: refs/heads/master@{#33133}
      >
      > TBR=adamk@chromium.org
      > # Not skipping CQ checks because original CL landed more than 1 days ago.
      > BUG=v8:4285,v8:3305,chromium:537816
      > LOG=Y
      >
      > Committed: https://crrev.com/adac5956c6216056a211cfaa460a00ac1500d8f8
      > Cr-Commit-Position: refs/heads/master@{#33162}
      
      TBR=adamk@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4285,v8:3305,chromium:537816
      
      Review URL: https://codereview.chromium.org/1571793002
      
      Cr-Commit-Position: refs/heads/master@{#33189}
      23235b5f
  22. 07 Jan, 2016 1 commit
    • littledan's avatar
      Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7... · adac5956
      littledan authored
      Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
      
      Reason for revert:
      Causes frequent crashes in Canary: chromium:537816
      
      Original issue's description:
      > Ship ES2015 sloppy-mode function hoisting, let, class
      >
      > This patch doesn't ship all features of ES2015 variable/scoping
      > changes, notably omitting the removal of legacy const. I think
      > function hoisting, let and class in sloppy mode can stand to
      > themselves as a package, and the legacy const change is much
      > riskier and more likely to be reverted, so my intention is to
      > pursue those as a separate, follow-on patch.
      >
      > R=adamk@chromium.org
      > BUG=v8:4285,v8:3305
      > LOG=Y
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      >
      > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
      > Cr-Commit-Position: refs/heads/master@{#33133}
      
      TBR=adamk@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      BUG=v8:4285,v8:3305,chromium:537816
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1565263002
      
      Cr-Commit-Position: refs/heads/master@{#33162}
      adac5956
  23. 06 Jan, 2016 1 commit
    • littledan's avatar
      Ship ES2015 sloppy-mode function hoisting, let, class · fcff8588
      littledan authored
      This patch doesn't ship all features of ES2015 variable/scoping
      changes, notably omitting the removal of legacy const. I think
      function hoisting, let and class in sloppy mode can stand to
      themselves as a package, and the legacy const change is much
      riskier and more likely to be reverted, so my intention is to
      pursue those as a separate, follow-on patch.
      
      R=adamk@chromium.org
      BUG=v8:4285,v8:3305
      LOG=Y
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      
      Review URL: https://codereview.chromium.org/1551443002
      
      Cr-Commit-Position: refs/heads/master@{#33133}
      fcff8588
  24. 22 Dec, 2015 1 commit
  25. 12 Dec, 2015 1 commit
  26. 08 Dec, 2015 1 commit
  27. 25 Nov, 2015 3 commits
    • adamk's avatar
      Run all message tests with a variant that forces preparsing · 802ea71e
      adamk authored
      This will make sure that message tests cover both the parser and preparser
      paths, just as we do for parsing-related cctests.
      
      BUG=v8:4372
      LOG=n
      
      Review URL: https://codereview.chromium.org/1469383004
      
      Cr-Commit-Position: refs/heads/master@{#32307}
      802ea71e
    • adamk's avatar
      [es6] Self-assignment in a default parameter initializer should throw · b6e9f625
      adamk authored
      The first bug was that there are two different "initialization positions"
      passed into PatternRewriter::DeclareAndInitializeVariables, and we weren't
      setting them all properly for this case.
      
      After further code review, it became clear that we weren't even recording
      the correct position (the end of the initializer expression).
      
      The combination of those two bugs caused the hole check elimination code
      in full-codegen to skip emitting a hole check.
      
      This patch takes care of both of those things. A follow-up will try
      to reduce the number of "initializer positions" we track in the
      variable declaration code.
      
      R=littledan@chromium.org
      BUG=v8:4568
      LOG=n
      
      Review URL: https://codereview.chromium.org/1468143004
      
      Cr-Commit-Position: refs/heads/master@{#32237}
      b6e9f625
    • 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
  28. 18 Nov, 2015 1 commit
  29. 05 Nov, 2015 3 commits