1. 03 Dec, 2020 1 commit
  2. 12 Nov, 2020 1 commit
  3. 03 Nov, 2020 2 commits
  4. 10 Aug, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [ast] Store correct source position on ThisExpression · 8a9e3f64
      Sathya Gunasekaran authored
      Previously, all ThisExpression's had kNoSourcePositions leading to
      incorrect error messages like this:
      
        ➜ d8 -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: undefined is not a function
        function t() { for (const x of this) {} } t();
                  ^
        TypeError: undefined is not a function
            at t (unnamed:1:11)
            at unnamed:1:43
      
      
      This patch allows creation of a ThisExpression with a source position,
      leading to a better error message:
      
        ➜ d8  -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: this is not iterable
        function t() { for (const x of this) {} } t();
                                       ^
        TypeError: this is not iterable
            at t (unnamed:1:32)
            at unnamed:1:43
      
      
      This patch does not remove the existing cached version of
      ThisExpression and instead creates a new one when required.
      
      Bug: v8:6513
      Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69300}
      8a9e3f64
  5. 24 Jun, 2020 1 commit
  6. 27 Apr, 2020 1 commit
  7. 31 Mar, 2020 1 commit
  8. 26 Mar, 2020 1 commit
  9. 25 Feb, 2020 1 commit
  10. 18 Feb, 2020 1 commit
  11. 05 Feb, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [callprinter] Correctly point to the incorrect spread arg · 1d0693e2
      Sathya Gunasekaran authored
      The source position is set to the function call (console.log) not the
      spread (..x), in the bytecode generator, as the spread operation is
      done as part of the CallWithSpread bytecode.
      
      The CallPrinter stops at the function call and doesn't look at the
      arguments as well (in CallPrinter::VisitCall) to see if the error is
      from an incorrect spread operation.
      
      
      With this patch, we pass some state to the CallPrinter in the
      CallWithSpread error case and check that in CallPrinter::VisitCall
      before returning.
      
      For the given source string:
      ```
      x = undefined;
      console.log(1, ...x);
      ```
      
      Previously, the error was -
      
      ```
      test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
      console.log(1, ...x);
              ^
      TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
          at test.js:2:9
      ```
      
      
      Now, the error is -
      
      ```
      _test.js:2: TypeError: x is not iterable (cannot read property undefined)
      console.log(1, ...x);
                        ^
      TypeError: x is not iterable (cannot read property undefined)
          at _test.js:2:9
      ```
      
      Bug: v8:10038
      Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66131}
      1d0693e2
  12. 30 Jan, 2020 1 commit
  13. 05 Nov, 2019 1 commit
    • Eric Leese's avatar
      V8 Wasm locations should always be based on byte offsets · 5c23e6b5
      Eric Leese authored
      Currently there are two ways wasm locations are represented in the
      inspector. This remains unchanged for now. Also, currently there are
      multiple ways location is represented within V8, with the line number
      sometimes being a function index and sometimes being 0, and the column
      number being a byte offset which is sometimes function relative and
      sometimes module relative. With this change, the line number is never
      used within V8 (it is always 0), and the column number is always a
      byte offset from the beginning of the module. This simplifies
      translation logic and keeps it in one place, and will simplify future
      changes to wasm location representation in the inspector API.
      
      Bug: chromium:1013527
      Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
      Commit-Queue: Eric Leese <leese@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64774}
      5c23e6b5
  14. 24 Oct, 2019 1 commit
  15. 24 Sep, 2019 1 commit
  16. 30 Aug, 2019 2 commits
    • Leszek Swirski's avatar
      Reland "[destructuring] Elide coercible check for simple keys" · ef2df57a
      Leszek Swirski authored
      This is a reland of 1fba0441
      Chromium expectation tests have been disabled, and will be enabled
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      >
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      >
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      >
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=verwaest@chromium.org
      
      Bug: chromium:999473
      Change-Id: Ib0b2e4be433c50521ba1722e1c06b672bfefa405
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777702Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63477}
      ef2df57a
    • Joyee Cheung's avatar
      [class] implement private accessors · df12eb19
      Joyee Cheung authored
      This patch implements the access of private accessors by loading the
      referenced component from the AccessorPair associated with private
      name variables. It also makes the error messages for invalid kind
      of private accessor access more specific.
      
      Bug: v8:8330
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Change-Id: I6d441cffb85f8d9cd0417ec9b6ae20f3e34ef418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695205Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#63474}
      df12eb19
  17. 29 Aug, 2019 2 commits
    • Adam Klein's avatar
      Revert "[destructuring] Elide coercible check for simple keys" · 28fa4cb4
      Adam Klein authored
      This reverts commit 1fba0441.
      
      Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      > 
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      > 
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      > 
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63465}
      28fa4cb4
    • Leszek Swirski's avatar
      [destructuring] Elide coercible check for simple keys · 1fba0441
      Leszek Swirski authored
      Simple object destructuring, such as `let {a,b} = o`, is less efficient
      than the equivalent assignments `let a = o.a; let b = o.b`. This is
      because it does a nil check of `o` before the assignments. However, this
      nil check is not strictly necessary for simple (i.e. non-computed) names,
      as there will be an equivalent nil check on the first access to o in
      `o.a`. For computed names the computation is unfortunately obervable.
      
      So, we can elide the nil check when the first property (if any) of the
      destructuring target is a non-computed name. This messes a bit with our
      error messages, so we re-use the CallPrinter to also find destructuring
      assignment based errors, and fiddle with the error message there. As
      a side-effect, we also get out the object name in the AST, so we can
      output a slightly nicer error message.
      
      Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63453}
      1fba0441
  18. 08 Jul, 2019 1 commit
  19. 03 Jul, 2019 2 commits
  20. 28 Jun, 2019 2 commits
  21. 27 Jun, 2019 1 commit
  22. 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
  23. 19 Jun, 2019 1 commit
  24. 13 Jun, 2019 1 commit
  25. 11 Jun, 2019 2 commits
  26. 20 May, 2019 3 commits
  27. 09 May, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Fix source positions for rethrown exceptions. · 89272565
      Michael Starzinger authored
      This fixes the source position printed in the stack trace for exceptions
      rethrown from within Wasm code. This only affects the message propagated
      to the console, not the trace stored as part of the exception object.
      
      Note that there still is a more fundamental issues with preserving the
      original message of a caught exception and funneling it through to each
      rethrow site, which is still missing. This change just makes sure that
      the interpreter and TurboFan are consistent.
      
      R=clemensh@chromium.org
      TEST=message/fail/wasm-exception-rethrow
      BUG=v8:8091
      
      Change-Id: Iac04149ded3c54f5b23faeb83b1228081bbd3dfa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598754Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61374}
      89272565
  28. 08 May, 2019 1 commit
  29. 06 May, 2019 1 commit
  30. 01 May, 2019 1 commit
  31. 09 Apr, 2019 1 commit
  32. 05 Apr, 2019 1 commit