1. 09 Jan, 2017 1 commit
  2. 05 Jan, 2017 1 commit
  3. 16 Dec, 2016 1 commit
    • littledan's avatar
      Remove class fields desugaring · 61833f5b
      littledan authored
      This patch removes parser code implementing desugaring for ESnext
      public and private fields on classes. The desugaring should probably
      be implemented in the interpreter instead, and more work needs to go
      into optimization and debugger support. The actual parsing of class
      fields is left in, as the syntax is relatively stable, and there are
      strong cctests for the grammar.
      
      R=marja
      BUG=v8:5367
      
      Review-Url: https://codereview.chromium.org/2578893005
      Cr-Commit-Position: refs/heads/master@{#41776}
      61833f5b
  4. 13 Dec, 2016 1 commit
  5. 12 Dec, 2016 1 commit
  6. 07 Dec, 2016 2 commits
  7. 06 Dec, 2016 1 commit
  8. 02 Dec, 2016 1 commit
    • vogelheim's avatar
      Remove unused code for IsFutureStrictReserved. · 07eca01b
      vogelheim authored
      This apparently gradually fell out of use after the more general
      Token::IsIdentifer was introduced, and whoever left last forgot to
      turn out the lights.
      
      The only remaining use was in an assertion in DeclareLabel, but
      meanwhile DeclareLabel is only called if IsIdentifier. I added re-formulated assertions, just in case.
      
      R=verwaest@chromium.org
      BUG=v8:4947
      
      Review-Url: https://codereview.chromium.org/2549493002
      Cr-Commit-Position: refs/heads/master@{#41452}
      07eca01b
  9. 01 Dec, 2016 1 commit
  10. 30 Nov, 2016 1 commit
  11. 28 Nov, 2016 2 commits
    • jochen's avatar
      Assign unique IDs to FunctionLiterals · cfebe603
      jochen authored
      They're supposed to be stable across several parse passes, so we'll also
      store them in the associated SharedFunctionInfos
      
      To achieve this, the PreParser and Parser need to generated the same number of
      FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of
      class literals.
      
      For regular functions, the function IDs are assigned in the order they occur in
      the source. For arrow functions, however, we only know that it's an arrow function
      after parsing the parameter list, and so the ID assigned to the arrow function is
      larger than the IDs assigned to functions defined in the parameter list. This
      implies that we have to reset the function ID counter to before the parameter list
      when re-parsing an arrow function. To be able to do this, we store the number of
      function literals found in the parameter list of arrow functions as well.
      
      BUG=v8:5589
      
      Review-Url: https://codereview.chromium.org/2481163002
      Cr-Commit-Position: refs/heads/master@{#41309}
      cfebe603
    • marja's avatar
      Parser: store parameters in a ThreadedList instead of ZoneList. · b31cbbd4
      marja authored
      ThreadedList is more memory-efficient than ZoneList. This also enables
      us to use ThreadedList when making Preparser track parameters (upcoming
      work).
      
      BUG=v8:5501
      
      Review-Url: https://codereview.chromium.org/2531593002
      Cr-Commit-Position: refs/heads/master@{#41307}
      b31cbbd4
  12. 23 Nov, 2016 1 commit
  13. 17 Nov, 2016 1 commit
    • neis's avatar
      [parser,ast] Simplify MarkExpressionAsAssigned. · 48bbd1a7
      neis authored
      There's no need to return anything.
      
      Also add a DCHECK to make sure that we never mark a variable proxy as assigned
      that is already resolved (to avoid potential inconsistency with the variable's
      maybe_assigned status).
      
      R=littledan@chromium.org
      CC=mstarzinger@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2504613002
      Cr-Commit-Position: refs/heads/master@{#41072}
      48bbd1a7
  14. 16 Nov, 2016 1 commit
  15. 15 Nov, 2016 2 commits
  16. 09 Nov, 2016 1 commit
  17. 07 Nov, 2016 2 commits
  18. 04 Nov, 2016 1 commit
    • verwaest's avatar
      Preparse lazy function parameters · 4ff2cafe
      verwaest authored
      Parameters of a lazily parsed function used to be parsed eagerly, and parameter
      handling was split between Parser::ParseFunctionLiteral and
      ParseEagerFunctionBody, leading to inconsistencies.
      
      After this CL, we preparse (lazy parse) the parameters of lazily parsed
      functions.
      
      (For arrow functions, we cannot do that ofc.)
      
      This is needed for later features (PreParser with scope analysis).
      
      -- CL adapted from marja's https://codereview.chromium.org/2411793003/
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2472063002
      Cr-Commit-Position: refs/heads/master@{#40771}
      4ff2cafe
  19. 25 Oct, 2016 1 commit
  20. 14 Oct, 2016 2 commits
    • verwaest's avatar
      Drop Lazy from parser method names and events · 7899fcc5
      verwaest authored
      BUG=
      
      Review-Url: https://codereview.chromium.org/2414383002
      Cr-Commit-Position: refs/heads/master@{#40318}
      7899fcc5
    • marja's avatar
      Remove "is function lazy" logic from Preparser + tiny error reporting refactoring. · 97fe83c7
      marja authored
      It doesn't need to have this logic.
      
      ParseLazyFunctionLiteralBody is basically just ParseStatementList
      + log the function position. But PreParser doesn't need to have
      the "which functions to log" logic, since logging the function is
      always done exactly when Parser falls back to PreParser. (See
      PreParseLazyFunction.)
      
      So in the current state, PreParser would log several functions in
      a SingletonLogger, and only the last one would take
      effect (that's the one Parser also logs in SkipLazyFunctionBody).
      
      Also updated test-parsing/Regress928 to produce the preparse data
      the way we do now (i.e., not running the PreParser directly, but
      running the Parser).
      
      Error reporting: when PreParser finds an error, it doesn't need
      to ReportUnexpectedToken in PreParseLazyFunction, since it
      already has reported the error whenever it found it.
      
      BUG=v8:5515
      
      Review-Url: https://codereview.chromium.org/2421833002
      Cr-Commit-Position: refs/heads/master@{#40315}
      97fe83c7
  21. 13 Oct, 2016 2 commits
  22. 10 Oct, 2016 1 commit
  23. 07 Oct, 2016 1 commit
  24. 04 Oct, 2016 1 commit
  25. 30 Sep, 2016 1 commit
  26. 28 Sep, 2016 4 commits
  27. 27 Sep, 2016 4 commits
  28. 26 Sep, 2016 1 commit