1. 27 Aug, 2018 1 commit
    • Peter Marshall's avatar
      Revert "[cleanup] Replace ZoneList with ZoneVector for parser reported_errors_" · 3727b265
      Peter Marshall authored
      This reverts commit 133a6815.
      
      Reason for revert: Regresses parsing time
      
      Original change's description:
      > [cleanup] Replace ZoneList with ZoneVector for parser reported_errors_
      > 
      > We use a ZoneVector because we do a fair amount of random access e.g.
      > in ExpressionClassifier::Accumulate() so the vector is better suited
      > than ZoneChunkList as it has constant time random access.
      > 
      > Bug: v8:6333
      > Change-Id: I83e1de60ee8fe319cfa5ce77fc5f5f86beb5307d
      > Reviewed-on: https://chromium-review.googlesource.com/1054672
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55315}
      
      TBR=neis@chromium.org,petermarshall@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6333
      Change-Id: Ib89f0aa1f27b7d6dbbf21af60ed7d1bcd2c0b7d3
      Reviewed-on: https://chromium-review.googlesource.com/1189803Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55427}
      3727b265
  2. 22 Aug, 2018 1 commit
  3. 20 Aug, 2018 1 commit
  4. 02 Feb, 2018 1 commit
  5. 15 Dec, 2017 1 commit
  6. 13 Nov, 2017 1 commit
    • Adam Klein's avatar
      [parser] Greatly simplify Array spread rewriting code · 18cac20c
      Adam Klein authored
      Since each Array literal containing a spread is individually queued for
      rewriting, there's no need for an AstVisitor here: a simple linear
      pass through the queue is sufficient.
      
      This patch deletes AstExpressionRewriter and all the machinery supporting
      it in the AST. This code was built with the idea of using it as
      a general expression rewriting mechanism in the parser, but those use
      cases never materialized, and Array spread remains the only thing
      that used this code.
      
      Bug: v8:6092
      Change-Id: I754c4883099e840881b005f20216f86e57721d5a
      Reviewed-on: https://chromium-review.googlesource.com/765051Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49337}
      18cac20c
  7. 06 Oct, 2016 1 commit
  8. 24 Sep, 2016 1 commit
  9. 01 Sep, 2016 1 commit
  10. 26 Aug, 2016 3 commits
  11. 25 Aug, 2016 3 commits
    • adamk's avatar
      Centralize and standardize logic for ExpressionClassifier accumulation · 51c186dd
      adamk authored
      Previously the calls to ExpressionClassifier::Accumulate() each chose
      slightly different sets of productions to accumulate, and it turned
      out that these were in some cases broader than needed and in some
      cases less broad.
      
      The existence of some grab-bag production bitmasks like
      ExpressionClassifier::ExpressionProductions made this situation more
      error-prone (for example, that production was missing AsyncArrowFormalParametersProduction).
      
      This patch removes all "grab-bags" besides AllProductions. In some of
      the places where code was using those grab-bags for convenience, it
      switches them to use negation of AllProductions. In other, specifically
      those having to do with expressions that are disallowed anywhere in
      a sub-expression of a parameter list, I've added a new method on
      ExpressionClassifier to centralize the logic.
      
      The aforementioned centralization/addition of
      AsyncArrowFormalParametersProduction fixes several cases where we were
      failing to report an error for 'await' in some contexts; I've added
      those test cases.
      
      The patch also narrows all cases to exactly the set or productions
      necessary, with a comment on each explaining the choice.
      
      BUG=v8:4483
      
      Review-Url: https://codereview.chromium.org/2271063002
      Cr-Commit-Position: refs/heads/master@{#38918}
      51c186dd
    • vogelheim's avatar
      Separate DuplicateFinder from Scanner. · 5b9b44d1
      vogelheim authored
      DuplicateFinder isn't actually used by the Scanner, except for one
      convenience function which we should probably remove, also.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2281443002
      Cr-Commit-Position: refs/heads/master@{#38904}
      5b9b44d1
    • nikolaos's avatar
      [parser] Clean up (pre)parser traits, part 5, last · ba9367db
      nikolaos authored
      This patch moves the following methods from the traits objects to
      the (pre)parser implementation objects:
      
      - AddFormalParameter
      - AddParameterInitializationBlock
      - DeclareFormalParameter
      - ExpressionListToExpression
      - GetNonPatternList
      - GetReportedErrorList
      - IsTaggedTemplate
      - MaterializeUnspreadArgumentsLiterals
      - NoTemplateTag
      - ParseArrowFunctionFormalParameterList
      - ReindexLiterals
      - SetFunctionNameFromIdentifierRef
      - SetFunctionNameFromPropertyName
      
      It moves the Void method from the preparser traits object to the
      preparser implementation object.  It also removes the traits zone
      method and replaces it with that of ParserBase, which it turns to
      public.
      
      After all this, the traits objects contain just typedefs and the
      delegate methods are no more necessary.
      
      R=adamk@chromium.org, marja@chromium.org
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2277843002
      Cr-Commit-Position: refs/heads/master@{#38892}
      ba9367db
  12. 23 Aug, 2016 1 commit
    • adamk's avatar
      [cleanup] Eliminate Forgive* methods on ExpressionClassifier · 1bf95207
      adamk authored
      The only two places where these Forgive methods were called
      was in ParseAssignmentExpression just at the time we were
      calling Accumulate(). So instead of Forgiving, we can simply
      not accumulate the bits that would have been forgiven.
      
      Also slightly restructures the nearby code in
      ParseAssignmentExpression, and removes the use of non-const
      references in ExpressionClassifier.
      
      Review-Url: https://codereview.chromium.org/2267223002
      Cr-Commit-Position: refs/heads/master@{#38839}
      1bf95207
  13. 22 Aug, 2016 1 commit
    • adamk's avatar
      [async functions] Disallow 'await' in arrow params inside async functions · 232a3360
      adamk authored
      The following code was previously accepted:
      
        async function f() {
          let g = (await) => {};
        }
      
      But per the spec, using 'await' is disallowed in arrow parameters
      by an early error rule (just as 'yield' is disallowed in arrow
      params inside generators).
      
      There was special logic in ParseUnaryExpression which seems to have been
      there only to allow that case. Having removed it, we get a SyntaxError in
      the right cases anyway when ParseUnaryExpression chokes on whatever
      illegal token follows 'await' in the cases this code previously handled.
      
      Also removes the unnecessary AsyncBindingPatternProduction enum value.
      
      R=caitp@igalia.com, littledan@chromium.org
      BUG=v8:4483
      
      Review-Url: https://codereview.chromium.org/2258313002
      Cr-Commit-Position: refs/heads/master@{#38802}
      232a3360
  14. 20 Aug, 2016 1 commit
    • gsathya's avatar
      [parser] Allow duplicate __proto__ keys in patterns · fc52e323
      gsathya authored
      This patch subsumes CoverInitializedNameProduction to create an ObjectLiteralProduction which is now used to report the duplicate proto error as well.
      
      This patch also changes ObjectLiteralChecker::CheckProperty
      to record an ObjectLiteralProduction error instead of
      bailing out immediately. Once we realize that we're in a
      pattern, we rewind the error, otherwise we report the
      error.
      
      BUG=v8:5121
      
      Review-Url: https://codereview.chromium.org/2255353002
      Cr-Commit-Position: refs/heads/master@{#38764}
      fc52e323
  15. 19 Aug, 2016 1 commit
  16. 13 Jun, 2016 1 commit
  17. 10 Jun, 2016 1 commit
    • nikolaos's avatar
      Reduce the memory footprint of expression classifiers · dfb8d333
      nikolaos authored
      This patch attempts to reduce the (stack) memory footprint of
      expression classifiers.  Instead of keeping space in each
      classifier for all possible error messages that will
      (potentially) be reported, if an expression turns out to be
      a pattern or a non-pattern, such error messages are placed in
      a list shared by the FunctionState and each classifier keeps a
      couple of indices in this list.  This requires that classifiers
      are used strictly in a stack-based fashion, which is also in line
      with my previous patch for revisiting non-pattern rewriting.
      
      R=adamk@chromium.org
      BUG=chromium:528697
      
      Review-Url: https://codereview.chromium.org/1708193003
      Cr-Commit-Position: refs/heads/master@{#36897}
      dfb8d333
  18. 16 May, 2016 1 commit
  19. 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
  20. 10 Mar, 2016 1 commit
  21. 19 Feb, 2016 3 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
    • 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
  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. 26 Nov, 2015 1 commit
  24. 15 Oct, 2015 1 commit
  25. 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
  26. 30 Sep, 2015 1 commit
  27. 28 Aug, 2015 1 commit
  28. 26 Aug, 2015 1 commit
  29. 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
  30. 07 Aug, 2015 1 commit
  31. 14 Jul, 2015 1 commit
  32. 10 Jun, 2015 1 commit
  33. 09 Jun, 2015 1 commit