1. 04 May, 2016 1 commit
  2. 02 May, 2016 1 commit
  3. 28 Apr, 2016 1 commit
  4. 27 Apr, 2016 1 commit
  5. 13 Apr, 2016 1 commit
  6. 11 Apr, 2016 1 commit
  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
  8. 16 Mar, 2016 1 commit
  9. 15 Mar, 2016 1 commit
  10. 07 Mar, 2016 1 commit
    • ishell's avatar
      [crankshaft] Support ES6 tail call elimination. · 22938040
      ishell authored
      HInvokeFunction and HApplyArguments instructions now support tail calling.
      
      Inlining of calls at tail position is not supported yet and therefore still disabled.
      
      The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.
      
      TBR=bmeurer@chromium.org
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1760253003
      
      Cr-Commit-Position: refs/heads/master@{#34542}
      22938040
  11. 04 Mar, 2016 1 commit
    • mvstanton's avatar
      Allow Crankshaft to tolerate certain do-expressions · 67838546
      mvstanton authored
      Crankshaft can't track operand/environment changes between arbitrary statements.
      We need that to fully support do-expressions. Instead, a subset is supported
      by bailing out on break statements, continue statements, and if we've made an
      OSR entry within a do-expression.
      
      This partial support is a good idea because do-expressions are a useful tool
      for desugaring during parsing.
      
      BUG=
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1769463002
      
      Cr-Commit-Position: refs/heads/master@{#34491}
      67838546
  12. 29 Feb, 2016 1 commit
  13. 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
    • jarin's avatar
      Ship Turbofan try-catch. · bd6ddb83
      jarin authored
      Another attempt, after the failing test (flushed bug) has been disabled
      in chromium (https://codereview.chromium.org/1710353002).
      
      Review URL: https://codereview.chromium.org/1713033002
      
      Cr-Commit-Position: refs/heads/master@{#34159}
      bd6ddb83
    • 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
  14. 18 Feb, 2016 1 commit
  15. 16 Feb, 2016 1 commit
  16. 12 Feb, 2016 2 commits
  17. 11 Feb, 2016 1 commit
  18. 19 Jan, 2016 1 commit
  19. 07 Jan, 2016 1 commit
  20. 31 Dec, 2015 1 commit
  21. 16 Dec, 2015 1 commit
  22. 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
  23. 01 Dec, 2015 2 commits
  24. 26 Nov, 2015 1 commit
  25. 18 Nov, 2015 1 commit
  26. 04 Nov, 2015 1 commit
  27. 21 Oct, 2015 1 commit
  28. 15 Oct, 2015 1 commit
  29. 14 Oct, 2015 1 commit
    • adamk's avatar
      Eagerly extract stack limit from Isolate in InitializeAstVisitor() · d317145d
      adamk authored
      Previously, any AstVisitor subclasses which wanted to make use of
      the shared stack overflow checking code needed to depend on Isolate.
      
      With this patch, it will be easy to create a second InitializeAstVisitor
      overload taking a stack_limit directly, for use in code that has no
      Isolate available (such as code running in the parser).
      
      AstVisitor subclasses which depended upon the isolate() accessor have
      been fixed to either have their own isolate_ member or get it from
      somewhere else convenient.
      
      Review URL: https://codereview.chromium.org/1387383005
      
      Cr-Commit-Position: refs/heads/master@{#31260}
      d317145d
  30. 13 Oct, 2015 1 commit
  31. 01 Oct, 2015 1 commit
  32. 28 Sep, 2015 2 commits
  33. 21 Sep, 2015 1 commit
    • littledan's avatar
      Implement sloppy-mode block-defined functions (Annex B 3.3) · e5ff10d7
      littledan authored
      ES2015 specifies very particular semantics for functions defined in blocks.
      In strict mode, it is simply a lexical binding scoped to that block. In sloppy
      mode, in addition to that lexical binding, there is a var-style binding in
      the outer scope, which is overwritten with the local binding when the function
      declaration is evaluated, *as long as* introducing ths var binding would not
      create a var/let conflict in the outer scope.
      
      This patch implements the semantics by introducing a DelegateStatement, which
      is initially filled in with the EmptyStatement and overwritten with the
      assignment when the scope is closed out and it can be checked that there is
      no conflict.
      
      This patch is tested with a new mjsunit test, and I tried staging it and running
      test262, finding that the tests that we have disabled due to lack of Annex B
      support now pass.
      
      R=adamk,rossberg
      LOG=Y
      BUG=v8:4285
      
      Review URL: https://codereview.chromium.org/1332873003
      
      Cr-Commit-Position: refs/heads/master@{#30842}
      e5ff10d7
  34. 10 Sep, 2015 1 commit
    • mvstanton's avatar
      Vector ICs: The Oracle needs to report feedback for the object literals and the count operation. · 752b0308
      mvstanton authored
      The refactoring is because it's awkward and error-prone to deterimine which IC slot an
      ObjectLiteralProperty uses for feedback. The fix is for each one to know it's own slot. In the
      numbering pass, we allocate slots for the ObjectLiteral, then hand out those slots into the
      properties.
      
      It adds one word to the ObjectLiteralProperty expression - I'm investigating if thats a
      problem.
      
      This changes makes compiling the object literal cleaner across the three compilers. Also, the
      slot allocation logic in ObjectLiteral::ComputeFeedbackRequirements() was refactoring to mimic
      the style in full-codegen. This is useful since it must remain in sync with
      FullCodegen::VisitObjectLiteral().
      
      Review URL: https://codereview.chromium.org/1321993004
      
      Cr-Commit-Position: refs/heads/master@{#30686}
      752b0308