1. 31 Mar, 2016 1 commit
  2. 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
  3. 18 Mar, 2016 2 commits
  4. 17 Mar, 2016 1 commit
  5. 16 Mar, 2016 1 commit
  6. 15 Mar, 2016 2 commits
  7. 10 Mar, 2016 1 commit
  8. 08 Mar, 2016 2 commits
  9. 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
  10. 06 Mar, 2016 1 commit
    • neis's avatar
      Get rid of the different kinds of yield in the AST & full-codegen. · f24dffea
      neis authored
      Now there is just one kind, corresponding to what was called "initial" before.
      Replacement for "suspend": when the parser sees a yield in JS code, it
      will turn it into a Yield node but wrap its argument in an iterator result
      object.  Replacement for "final": the parser simply inserts a return statement
      instead.
      
      R=littledan@chromium.org, mstarzinger@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1751613004
      
      Cr-Commit-Position: refs/heads/master@{#34515}
      f24dffea
  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. 02 Mar, 2016 1 commit
  13. 01 Mar, 2016 1 commit
  14. 29 Feb, 2016 2 commits
  15. 26 Feb, 2016 1 commit
  16. 25 Feb, 2016 1 commit
  17. 19 Feb, 2016 6 commits
    • mvstanton's avatar
      ES6: Desugaring of instanceof to support @@hasInstance · deb7d5b0
      mvstanton authored
      This is a rework of the instanceof operator to support ES6 semantics
      (as per section 12.10.4 of the spec:
      https://tc39.github.io/ecma262/#sec-instanceofoperator).
      
      It's behind flag --harmony-instanceof for now, which is turned on for staging.
      
      BUG=v8:4447
      LOG=N
      
      Review URL: https://codereview.chromium.org/1692713005
      
      Cr-Commit-Position: refs/heads/master@{#34170}
      deb7d5b0
    • 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
    • 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
  18. 18 Feb, 2016 3 commits
    • adamk's avatar
      Remove strong mode support from Scope and Variable · 63efda35
      adamk authored
      This frees up one bit in FunctionKind, which I plan to make slightly
      more syntactic info about functions available in SharedFunctionInfo
      (needed for ES2015 Function.name support).
      
      BUG=v8:3956, v8:4760
      LOG=n
      
      Review URL: https://codereview.chromium.org/1704223002
      
      Cr-Commit-Position: refs/heads/master@{#34125}
      63efda35
    • ishell's avatar
      [es6] Disable tail call optimization in optimizing compilers for now. · 1d420199
      ishell authored
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1713533002
      
      Cr-Commit-Position: refs/heads/master@{#34115}
      1d420199
    • rossberg's avatar
      [es6] Implement for-of iterator finalization · cb1bf4af
      rossberg authored
      Implements iterator finalisation by desugaring for-of loops with an additional try-finally wrapper. See comment in parser.cc for details.
      
      Also improved some AST printing facilities while there.
      
      @Ross, I had to disable the bytecode generation test for for-of, because it got completely out of hand after this change (the new bytecode has 150+ lines). See the TODO that I assigned to you.
      
      Patch set 1 is WIP patch by Georg (http://crrev.com/1695583003), patch set 2 relative changes.
      
      @Georg, FYI, I changed the following:
      
      - Moved try-finally out of the loop body, for performance, and in order to be able to handle `continue` correctly.
      - Fixed scope management in ParseForStatement, which was the cause for the variable allocation failure.
      - Fixed pre-existing zone initialisation bug in rewriter, which caused the crashes.
      - Enabled all tests, adjusted a few others, added a couple more.
      
      BUG=v8:2214
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1695393003
      
      Cr-Commit-Position: refs/heads/master@{#34111}
      cb1bf4af
  19. 16 Feb, 2016 2 commits
  20. 12 Feb, 2016 2 commits
  21. 11 Feb, 2016 2 commits
  22. 08 Feb, 2016 2 commits
    • bmeurer's avatar
      [compiler] Remove the special case "prototype" load in class literals. · 1ffa4547
      bmeurer authored
      This allows us to remove the somewhat awkward BuildLoadObjectField
      from the AstGraphBuilder and also allows us to simplify fullcodegen
      for class literals.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1679813002
      
      Cr-Commit-Position: refs/heads/master@{#33815}
      1ffa4547
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      bmeurer authored
      Replace the somewhat awkward RestParamAccessStub, which would always
      call into the runtime anyway with a proper FastNewRestParameterStub,
      which is basically based on the code that was already there for strict
      arguments object materialization. But for rest parameters we could
      optimize even further (leading to 8-10x improvements for functions with
      rest parameters), by fixing the internal formal parameter count:
      
      Every SharedFunctionInfo has a formal_parameter_count field, which
      specifies the number of formal parameters, and is used to decide whether
      we need to create an arguments adaptor frame when calling a function
      (i.e. if there's a mismatch between the actual and expected parameters).
      Previously the formal_parameter_count included the rest parameter, which
      was sort of unfortunate, as that meant that calling a function with only
      the non-rest parameters still required an arguments adaptor (plus some
      other oddities). Now with this CL we fix, so that we do no longer
      include the rest parameter in that count. Thereby checking for rest
      parameters is very efficient, as we only need to check whether there is
      an arguments adaptor frame, and if not create an empty array, otherwise
      check whether the arguments adaptor frame has more parameters than
      specified by the formal_parameter_count.
      
      The FastNewRestParameterStub is written in a way that it can be directly
      used by Ignition as well, and with some tweaks to the TurboFan backends
      and the CodeStubAssembler, we should be able to rewrite it as
      TurboFanCodeStub in the near future.
      
      Drive-by-fix: Refactor and unify the CreateArgumentsType which was
      different in TurboFan and Ignition; now we have a single enum class
      which is used in both TurboFan and Ignition.
      
      R=jarin@chromium.org, rmcilroy@chromium.org
      TBR=rossberg@chromium.org
      BUG=v8:2159
      LOG=n
      
      Review URL: https://codereview.chromium.org/1676883002
      
      Cr-Commit-Position: refs/heads/master@{#33809}
      3ef573e9
  23. 05 Feb, 2016 2 commits
  24. 04 Feb, 2016 1 commit
    • adamk's avatar
      Support computed properties for ES2015 Function.name · 21c045a2
      adamk authored
      Adds a new runtime function, %DefineDataPropertyInLiteral, which
      takes a fifth argument specifying whether the property and value
      are syntactically such that the value is a function (or class)
      literal that should have its name set at runtime.
      
      The new runtime call also allows us to eliminate the now-redundant
      %DefineClassMethod runtime function.
      
      This should get much less ugly once we can desugar the "dynamic"
      part of object literals in the parser (but that work is currently
      blocked on having a performant way of desugaring literals).
      
      BUG=v8:3699, v8:3761
      LOG=n
      
      Review URL: https://codereview.chromium.org/1626423003
      
      Cr-Commit-Position: refs/heads/master@{#33756}
      21c045a2