1. 11 Sep, 2019 1 commit
  2. 10 Sep, 2019 1 commit
  3. 06 Sep, 2019 1 commit
  4. 04 Sep, 2019 1 commit
  5. 03 Sep, 2019 1 commit
  6. 29 Aug, 2019 1 commit
    • Leszek Swirski's avatar
      [scopes] Push sloppy eval check through eval scopes · f6057ff1
      Leszek Swirski authored
      Sloppy eval extends the outer declaration scope's context. This is also
      true for sloppy eval inside of other sloppy evals -- the outer declaration
      scope's context is extended rather than the outer sloppy eval's
      declaration scope. However, we consider eval scopes to also be declaration
      scopes, for the purposes of strict eval and caching lookup variables. So,
      we need to make sure that we skip through sloppy eval scopes when marking
      a scope as calls_sloppy_eval.
      
      In fact, we implement this rather as never marking sloppy eval scopes as
      calls_sloppy_eval, under the assumption that the parent scope will already
      have been marked calls_sloppy_eval by the outer eval.
      
      As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
      RecordEvalCall(), rename the variable to something more meaningful, and
      make Snapshotting to use a new calls_eval bit on Scope.
      
      Bug: chromium:996751
      Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63455}
      f6057ff1
  7. 27 Aug, 2019 1 commit
  8. 23 Aug, 2019 1 commit
  9. 21 Aug, 2019 1 commit
  10. 20 Aug, 2019 1 commit
    • Dan Elphick's avatar
      [parser] Fix bytecode mismatch for this · dd547367
      Dan Elphick authored
      Fixes bytecode mismatch between lazy and non-lazy where "this" was
      marked as maybe assigned in constructors that called the super
      constructor. Since this will return the hole in cases where it was not
      yet initialized by super (and the hole is explicitly handled by
      JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as
      a constant in all cases. In the case of lazy compilation case, "this"
      is never added to the ScopeInfo so is never seen as mutable.
      
      Bug: chromium:994719
      Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63283}
      dd547367
  11. 07 Aug, 2019 1 commit
  12. 01 Aug, 2019 1 commit
  13. 30 Jul, 2019 2 commits
  14. 26 Jul, 2019 1 commit
  15. 08 Jul, 2019 1 commit
  16. 03 Jul, 2019 2 commits
  17. 01 Jul, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Mark maybe_assigned recursively for shadowing vars · fc4bcce1
      Leszek Swirski authored
      The previous fix for this bug (crrev.com/c/1678365) pessimistically
      would mark all shadowed variables as maybe_assigned. Unfortunately,
      this doesn't work across a parse/preparse boundary, where the shadowing
      variable is found via Scope::AnalyzePartially while the shadowed
      variable is outside of the preparser entry point. In those cases, the
      referencing proxy is copied to the outer scope, in which case the
      dynamicness of the original lookup is lost and the maybe_assigned
      pessimisation no longer applies.
      
      This means that maybe_assigned status of a variable is dependent on
      which function is being parsed. In particular, it can cause bytecode
      to change on recompilation, causing issues for lazy source positions.
      
      This patch allows SetMaybeAssigned to walk its shadowed variables,
      and recursively set them to maybe_assigned too. Checking for
      maybe_assigned changing prevents this recursion from having a
      quadratic performance failure mode.
      
      Bug: v8:8510
      Bug: v8:9394
      Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62458}
      fc4bcce1
  18. 28 Jun, 2019 2 commits
  19. 26 Jun, 2019 2 commits
  20. 25 Jun, 2019 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Improve error when using import decl in a script · e101b9c0
      Sathya Gunasekaran authored
      Perform a best-effort check for module context and provide an
      appropriate error.
      
      As seen from the import-blah-script.js test, we could have invalid
      import expressions in a script context that could result in an error
      saying "Cannot use import statement outside a module" which isn't
      the ideal error because the error is an incorrect import
      expression.
      
      But, when the developer changes to a module context, the
      correct error is thrown.
      
      To fix this, we'd have to refactor and call ParseImportDeclaration,
      and then throw an appropriate error, which seems like a lot of
      overhead for not enough gain.
      
      Bug: v8:9392, v8:6513
      Change-Id: I520ebb490fff4d95743a7c751d4095db9a35d41b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675948Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62358}
      e101b9c0
  21. 21 Jun, 2019 1 commit
    • Daniel Bratell's avatar
      Clarifying another Regexp namespace · e446f182
      Daniel Bratell authored
      Right now there is both a v8::internal::RegExp class and a
      v8::RegExp class so when code says just "RegExp" the name lookup
      depends on what the compiler knows. In some jumbo builds the
      compiler suddenly knew about v8::internal::RegExp which made
      the symbol lookup choose that class instead of v8::RegExp.
      
      Bug: v8:9359
      Change-Id: Ic226d187a397ef2ed4e1e7b415c4f68ba72aa0e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669688
      Auto-Submit: Daniel Bratell <bratell@opera.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62305}
      e446f182
  22. 19 Jun, 2019 1 commit
  23. 18 Jun, 2019 1 commit
  24. 24 May, 2019 1 commit
  25. 23 May, 2019 2 commits
  26. 22 May, 2019 1 commit
  27. 21 May, 2019 1 commit
  28. 20 May, 2019 1 commit
  29. 17 May, 2019 2 commits
  30. 16 May, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Add dedicated FunctionLiteral counters · 3002ff44
      Jakob Gruber authored
      Prior to this CL, call counts at function scope were taken from the
      FeedbackVector::invocation_count field. This had two major drawbacks:
      1. for generator functions, these count the number of resumptions
      instead of the number of calls; and 2. the invocation count is not
      maintained in optimized code.
      
      The solution implemented here is to add a dedicated call counter at
      function scope which is incremented exactly once each time the
      function is called.
      
      A minor complication is that our coverage output format expects
      function-scope counts in the dedicated CoverageFunction object, and
      not as a CoverageBlock. Thus function-scope block counts are initially
      marked with magic positions, and later recognized and rewritten during
      processing.
      
      This CL thus fixes reported generator function call counts and enables
      optimizations in block coverage modes (more to come in a follow-up).
      
      Drive-by: Don't report functions with empty source ranges.
      
      Bug: v8:6000,v8:9148,v8:9212
      Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
      Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61574}
      3002ff44
  31. 13 May, 2019 1 commit
  32. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  33. 09 May, 2019 2 commits