1. 21 Feb, 2018 1 commit
  2. 19 Apr, 2017 1 commit
    • Adam Klein's avatar
      Remove "calls eval" bit from ParseInfo and PreParseData · 9b512732
      Adam Klein authored
      There's no reason to keep track, for a preparsed function itself,
      whether that function calls eval. All that matters is that the ancestor
      scopes are marked as having an inner scope which calls eval. The function
      will have its "calls eval" bit persisted if/when it's fully parsed.
      
      The only "behavioral" change in this patch is the removal of a DCHECK.
      
      Bug: v8:6092
      Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b
      Reviewed-on: https://chromium-review.googlesource.com/481223
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44732}
      9b512732
  3. 18 Apr, 2017 1 commit
  4. 10 Apr, 2017 1 commit
  5. 05 Apr, 2017 1 commit
  6. 29 Mar, 2017 1 commit
  7. 14 Mar, 2017 1 commit
  8. 16 Feb, 2017 1 commit
  9. 09 Jan, 2017 1 commit
  10. 28 Nov, 2016 1 commit
    • 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
  11. 15 Nov, 2016 1 commit
  12. 07 Nov, 2016 1 commit
    • verwaest's avatar
      [parser] Give preparser and parser independent loggers · 32105d21
      verwaest authored
      This
      - removes the ParserRecorder base class,
      - devirtualizes the LogFunction and LogMessage functions,
      - reuses the SingletonLogger for all preparser calls
      
      In a subsequent step the preparser should probably log directly to the CompleteParserRecorder rather than indirectly through the singleton logger...
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2474393003
      Cr-Commit-Position: refs/heads/master@{#40803}
      32105d21
  13. 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
  14. 09 Jun, 2016 1 commit
    • lpy's avatar
      Move hashmap into src/base. · 2fd55667
      lpy authored
      We ported hashmap.h into libsampler as a workaround before, so the main focus of
      this patch is to reduce code duplication. This patch moves the hashmap into
      src/base as well as creates DefaultAllocationPolicy using malloc and free.
      
      BUG=v8:5050
      LOG=n
      
      Review-Url: https://codereview.chromium.org/2010243003
      Cr-Commit-Position: refs/heads/master@{#36873}
      2fd55667
  15. 26 Nov, 2015 1 commit
  16. 01 Jun, 2015 1 commit
  17. 18 May, 2015 1 commit
  18. 09 Mar, 2015 1 commit
  19. 20 Feb, 2015 1 commit
  20. 12 Jan, 2015 1 commit
  21. 21 Oct, 2014 1 commit
  22. 04 Aug, 2014 1 commit
  23. 10 Jul, 2014 1 commit
  24. 30 Jun, 2014 1 commit
  25. 20 Jun, 2014 1 commit
  26. 03 Jun, 2014 1 commit
  27. 27 May, 2014 1 commit
  28. 26 May, 2014 2 commits
  29. 05 May, 2014 1 commit
  30. 29 Apr, 2014 1 commit
  31. 14 Apr, 2014 1 commit
  32. 01 Apr, 2014 1 commit
  33. 13 Mar, 2014 1 commit
  34. 25 Feb, 2014 1 commit
  35. 05 Jul, 2013 1 commit
  36. 16 Apr, 2013 1 commit
  37. 28 Feb, 2013 1 commit
  38. 19 May, 2011 1 commit
  39. 06 May, 2011 1 commit