1. 22 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Push variables of non-arrow parenthesized expression to parent · 7ff82992
      Toon Verwaest authored
      Parenthesized variable names are valid references for assignment. To make sure
      we can properly mark the variable as assigned, we should push parenthesized
      variables to the outer expression scope after the parenthesized expression is
      guaranteed to not be an arrow head; so that the variable list of the parent is
      complete.
      
      Technically we could probably get by with simply pushing a single variable,
      since more complex expressions aren't valid parenthesized assignment targets:
      (a) = ... and [(a),(b)] = ... are valid, but ([a,b]) = ... isn't.
      It doesn't really seem worth it though.
      
      Bug: chromium:1015372
      Change-Id: I095c35126742a14d0171537b9795f7258c33ab4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872389
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64455}
      7ff82992
  2. 21 Oct, 2019 1 commit
  3. 18 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Accumulate even if we already thought we had an error · 94d8fcb8
      Toon Verwaest authored
      At certain points in time we learn that we have to drop certain errors in the
      ExpressionScope. If an AccumulationScope appears between where we learn about
      the error and where we drop the error, we previously stopped accumulating,
      assuming that we're already going to fail anyway. Since we might drop the
      earlier error later; we can't early on this. Instead the accumulator should
      simply keep on accumulating, keeping the earlier error alive across
      accumulation.
      
      Bug: chromium:1015567
      Change-Id: I4d70643d02233fe82582b568a0a946eacf883880
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869198
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64384}
      94d8fcb8
  4. 10 Oct, 2019 2 commits
    • Joyee Cheung's avatar
      [class] fix undefined private name access in computed property keys · 7fa12e2a
      Joyee Cheung authored
      This patch implements https://github.com/tc39/proposal-class-fields/pull/269
      and makes sure we always throw TypeError when there is invalid private
      name access in computed property keys.
      
      Before this patch, private name variables of private fields and methods
      are initialized together with computed property keys in the order they
      are declared. Accessing undefined private names in the computed property
      keys thus fail silently.
      
      After this patch, we initialize the private name variables of private
      fields before we initialize the computed property keys, so that invalid
      access to private fields in the computed keys can be checked in the IC.
      We now also initialize the brand early, so that invalid access to private
      methods or accessors in the computed keys throw TypeError during brand
      checks - and since these accesses are guarded by brand checks, we can
      create the private methods and accessors after the class is
      defined, and merge the home object setting with the creation
      of the closures.
      
      Bug: v8:8330, v8:9611
      Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64225}
      7fa12e2a
    • Joyee Cheung's avatar
      [class] implement static private methods · 4e8c6281
      Joyee Cheung authored
      This patch refactors the declaration and allocation of the class variable, and
      implements static private methods:
      
      
      - The class variable is declared in the class scope with an explicit
        reference through class_scope->class_variable(). Anonymous classes
        whose class variable may be accessed transitively through static
        private method access use the dot string as the class name. Whether
        the class variable is allocated depending on whether it is used.
        Other references of the class variable in the ClassLiteral AST node
        and the ClassInfo structure are removed in favor of the reference
        through the class scope.
      - Previously the class variable was always (stack- or context-)
        allocated if the class is named. Now if the class variable is only
        referenced by name, it's stack allocated. If it's used transitively
        by access to static private methods, or may be used through eval,
        it's context allocated. Therefore we now use 1 less context slots
        in the class context if it's a named class without anyone referencing
        it by name in inner scopes.
      - Explicit access to static private methods or potential access to
        static private methods through eval results in forced context
        allocation of the class variables. In those cases, we save its index
        in context locals in the ScopeInfo and deserialize it later, so that
        we can check that the receiver of static private methods is the class
        constructor at run time. This flag is recorded as
        HasSavedClassVariableIndexField in the scope info.
      - Classes that need the class variable to be saved due to
        access to static private methods now save a
        ShouldSaveClassVariableIndexField in the preparse data so that the
        bits on the variables can be updated during a reparse. In the case
        of anonymous classes that need the class variables to be saved,
        we also re-declare the class variable after the reparse since
        the inner functions are skipped and we need to rely on the preparse
        data flags to remember declaring it.
      
      Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
      
      Bug: v8:8330
      Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64219}
      4e8c6281
  5. 09 Oct, 2019 1 commit
  6. 07 Oct, 2019 1 commit
  7. 04 Oct, 2019 1 commit
  8. 24 Sep, 2019 2 commits
  9. 23 Sep, 2019 1 commit
  10. 20 Sep, 2019 1 commit
  11. 18 Sep, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland^2 "Remove all custom CopyCharsUnsigned implementations" · 3b808dee
      Clemens Hammacher authored
      This is an unmodified reland of
      9febc505. Nosnap bots do not block
      LKGR any more: https://crbug.com/v8/9737#c10.
      
      Original change's description:
      > Reland "Remove all custom CopyCharsUnsigned implementations"
      >
      > This is a reland of 5d8c4890
      >
      > Original change's description:
      > > Remove all custom CopyCharsUnsigned implementations
      > >
      > > It's unclear whether the custom implementation have any advantage over
      > > the standard library one's.
      > > Since we update our toolchain and standard library regularly, it might
      > > well be the case that the custom implementations are slower by now.
      > >
      > > Thus this CL removes all {CopyCharsUnsigned} implementations and
      > > implements {CopyChars} generically using {std::copy_n}.
      > >
      > > Note that this does not touch the {MemMove} and {MemCopy} functions
      > > yet, as we have seen regressions when trying to remove them before
      > > (https://crbug.com/v8/8675#c5).
      > >
      > > R=leszeks@chromium.org
      > >
      > > Bug: v8:9396
      > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63808}
      >
      > Bug: v8:9396
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63823}
      
      TBR=leszeks@chromium.org
      
      Bug: v8:9396
      Change-Id: I793524d76b8b9c93d2a98c73e8d72967880fe1cf
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809362
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63857}
      3b808dee
  12. 17 Sep, 2019 2 commits
    • Adam Klein's avatar
      Revert "Reland "Remove all custom CopyCharsUnsigned implementations"" · 24c35b92
      Adam Klein authored
      This reverts commits 9febc505
      (along with followup commit 60624b56).
      
      Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145
      
      nosnap bots may be deprecated, but as long as they're in LKGR
      we need to mind them.
      
      Original change's description:
      > Reland "Remove all custom CopyCharsUnsigned implementations"
      >
      > This is a reland of 5d8c4890
      >
      > Original change's description:
      > > Remove all custom CopyCharsUnsigned implementations
      > >
      > > It's unclear whether the custom implementation have any advantage over
      > > the standard library one's.
      > > Since we update our toolchain and standard library regularly, it might
      > > well be the case that the custom implementations are slower by now.
      > >
      > > Thus this CL removes all {CopyCharsUnsigned} implementations and
      > > implements {CopyChars} generically using {std::copy_n}.
      > >
      > > Note that this does not touch the {MemMove} and {MemCopy} functions
      > > yet, as we have seen regressions when trying to remove them before
      > > (https://crbug.com/v8/8675#c5).
      > >
      > > R=leszeks@chromium.org
      > >
      > > Bug: v8:9396
      > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63808}
      >
      > Bug: v8:9396
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63823}
      
      TBR=leszeks@chromium.org,clemensh@chromium.org
      
      Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63854}
      24c35b92
    • Clemens Hammacher's avatar
      Reland "Remove all custom CopyCharsUnsigned implementations" · 9febc505
      Clemens Hammacher authored
      This is a reland of 5d8c4890
      
      Original change's description:
      > Remove all custom CopyCharsUnsigned implementations
      >
      > It's unclear whether the custom implementation have any advantage over
      > the standard library one's.
      > Since we update our toolchain and standard library regularly, it might
      > well be the case that the custom implementations are slower by now.
      >
      > Thus this CL removes all {CopyCharsUnsigned} implementations and
      > implements {CopyChars} generically using {std::copy_n}.
      >
      > Note that this does not touch the {MemMove} and {MemCopy} functions
      > yet, as we have seen regressions when trying to remove them before
      > (https://crbug.com/v8/8675#c5).
      >
      > R=leszeks@chromium.org
      >
      > Bug: v8:9396
      > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63808}
      
      Bug: v8:9396
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63823}
      9febc505
  13. 16 Sep, 2019 3 commits
  14. 13 Sep, 2019 1 commit
  15. 12 Sep, 2019 1 commit
  16. 11 Sep, 2019 1 commit
  17. 10 Sep, 2019 2 commits
  18. 06 Sep, 2019 1 commit
  19. 05 Sep, 2019 1 commit
    • Sigurd Schneider's avatar
      [debugger] Fix code coverage for async functions · 3b0f89d0
      Sigurd Schneider authored
      Async functions were not correctly fixed up for code coverage, which
      caused an additional uncovered range to be reported between a return
      statement and the closing bracket.
      
      This CL adds code that detects such ranges, and removes them, similarly
      to how the ranges are removed for normal functions. The removal process
      is different, because the parser rewrites async functions to contain a
      try-catch handling promise rejection.
      
      Change-Id: I73b08d64be74d26c32f2f9652d027430d4671251
      
      Bug: chromium:981313, v8:8381
      Change-Id: I82a7f0c54d3a48609ef5255a7659d9557e163566
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782837Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63561}
      3b0f89d0
  20. 04 Sep, 2019 1 commit
  21. 03 Sep, 2019 1 commit
  22. 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
  23. 27 Aug, 2019 2 commits
  24. 23 Aug, 2019 1 commit
  25. 21 Aug, 2019 1 commit
  26. 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
  27. 13 Aug, 2019 1 commit
  28. 12 Aug, 2019 2 commits
  29. 08 Aug, 2019 1 commit
  30. 07 Aug, 2019 1 commit
  31. 05 Aug, 2019 1 commit
  32. 01 Aug, 2019 1 commit