Skip to content

V
V8
Switch branch/tag
  1. 18 Aug, 2017 2 commits
    • Franziska Hinkelmann's avatar
      [es2015] Fix error for wrong offset in TypedArray · 96cd1cfb
      Franziska Hinkelmann authored 
      %TypedArray%.prototype.set should throw a range error for invalid offset.

Bug: v8:6729
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I2b2b64a82657ecabf136ec8f13b41e95a62b8f38
Reviewed-on: https://chromium-review.googlesource.com/620569
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47443}
      96cd1cfb
    • Adam Klein's avatar
      [ast] Save one pointer in most Function and Variable declaration node · 69b165db
      Adam Klein authored 
      Currently, Declaration stores a Scope pointer to whichever Scope the
declaration appeared in. This is used to disallow var declarations
being hoisted over lexical declarations. For example:

  {
    let x;
    { var x; }
  }

But in fact this is the only sort of case where storing the scope
is required: for lexical declarations (including function declarations
appearing in blocks), Declaration::scope() was always identical to
Declaration::proxy()->var()->scope(). That is, only var declarations
end up "nested" in this way.

This patch adds a subclass of VariableDeclaration to store the Scope.
Since the only thing that cares about that data is Scope analysis,
this isn't treated as a distinct AstNode::NodeType from VariableDeclaration,
leaving all AstVisitors untouched in the process.

Also reworked the logic in Scope::CheckConflictingVarDeclarations() for
clarity after making changes to accomodate the new code.

Change-Id: I6ee4298700508ab9e28a76ddb8504bae68bc473f
Reviewed-on: https://chromium-review.googlesource.com/619595
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47441}
      69b165db
  3. 02 Aug, 2017 1 commit
  5. 01 Aug, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Provide better error when destructuring callable · c805d5e3
      Sathya Gunasekaran authored 
      The patch changes CallPrinter's AST traversal to continue even after
the first positive match for an AST node. This helps us check for the
subsequent GetIterator AST node in case of destructuring.

We can not differentiate between the function call failing and the
GetIterator failing based on source position info. This would involve
runtime checks costing performance.

Instead of providing an incorrect error, we provide both the
possiblities to user and allow them to disambiguate.

Previously,
  d8> function f() { return 5; }
  undefined
  d8> var [a] = f();
  (d8):1: TypeError: f is not a function
  var [a] = f();
            ^
  TypeError: f is not a function
      at (d8):1:11


Now,
  d8> function f() { return 5; }
  undefined
  d8> var [a] = f();
  (d8):1: TypeError: f is not a function or its return value is not iterable
  var [a] = f();
            ^
  TypeError: f is not a function or its return value is not iterable
      at (d8):1:11

Bug: v8:6616, v8:6513
Change-Id: I3d6427f10cae54951b0ad0e5ddcbe802bb7191c1
Reviewed-on: https://chromium-review.googlesource.com/594894
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47025}
      c805d5e3
  7. 25 Jul, 2017 1 commit
  9. 18 Jul, 2017 1 commit
  11. 17 Jul, 2017 1 commit
    • Sathya Gunasekaran's avatar
      Fix error message while array destructuring undefined · 94ce16b7
      Sathya Gunasekaran authored 
      Previously,
  ➜  v8 (master) :heavy_check_mark: ./out.gn/x64.optdebug/d8
  V8 version 6.1.0 (candidate)
  d8> var x = undefined
  undefined
  d8> var [a] = x
  (d8):1: TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
  var [a] = x
            ^
  TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
      at (d8):1:11

Now,
  ➜  v8 (fix-iterator) :heavy_check_mark: ./out.gn/x64.optdebug/d8
  V8 version 6.1.0 (candidate)
  d8> var x = undefined
  undefined
  d8> var [a] = x
  (d8):1: TypeError: x is not iterable
  var [a] = x
            ^
  TypeError: x is not iterable
      at (d8):1:11


Bug: v8:6599, v8:6513
Change-Id: I71287a19166af0289e8f7708b8f41ad003ae87ae
Reviewed-on: https://chromium-review.googlesource.com/571175
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46723}
      94ce16b7
  13. 14 Jul, 2017 1 commit
  15. 10 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      Reland "[parser] moved load property position after dot" · 61ea3243
      Alexey Kozyatinskiy authored 
      This is a reland of 5b44ba0e
Original change's description:
> (Reland) [parser] moved load property position after dot
> 
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
> 
> R=jgruber@chromium.org
> TBR=marja@chromium.org
> 
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}

TBR=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng

Bug: v8:6425
Change-Id: I5eba5fe43ad31c5c781ffcc8c604cd9c98baa57e
Reviewed-on: https://chromium-review.googlesource.com/565907Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46542}
      61ea3243
  17. 08 Jul, 2017 1 commit
  19. 07 Jul, 2017 1 commit
  21. 06 Jul, 2017 1 commit
  23. 29 Jun, 2017 1 commit
  25. 23 Jun, 2017 2 commits
  27. 19 Jun, 2017 1 commit
  29. 16 Jun, 2017 1 commit
  31. 15 Jun, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Better error message when destructuring against undefined/null · bc2c785c
      Sathya Gunasekaran authored 
      Previously, when destructuring against null or undefined we would
print:

  d8> var { x } = null
  (d8):1: TypeError: Cannot match against 'undefined' or 'null'.
  var { x } = null
  ^
  TypeError: Cannot match against 'undefined' or 'null'.
      at (d8):1:1


The above message uses the term "match" which isn't a common term in
JavaScript to describe destructuring. This message also doesn't
provide the name of the property that fails destructuring.

This patch changes the error message to be:

  d8> var { x } = null;
  (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
  var { x } = null;
        ^
  TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
      at (d8):1:1

This patch changes the message to say "destructure" instead of "match".

This patch adds support for printing property names that are string
literals. We iterate through every property and pick the first string
literal property name if it exists. This provides at least some
feedback to the developer.

This patch also makes the pointer point to the position of the
property name that fails destructuring.

For computed and numeric property names, we print a generic error:
  d8> var { 1: x } = null
  (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
  var { 1: x } = null
  ^
  TypeError: Cannot destructure against 'undefined' or 'null'.
      at (d8):1:1

Bug: v8:6499
Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45965}
      bc2c785c
  33. 12 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Decode and use module name · 237d21b2
      Clemens Hammacher authored 
      * add functionality to wasm-module-builder.js to emit the module name
  in the name section.
* extend WasmModule to store the module name length and offset.
* add functionality to module-decoder.cc to decode the module name.
* use the module name for printing stack traces. more uses should
  follow.
* extend one message test to contain a module name.

R=ahaas@chromium.org

Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f
Reviewed-on: https://chromium-review.googlesource.com/530366Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45846}
      237d21b2
  35. 09 Jun, 2017 1 commit
  37. 19 May, 2017 1 commit
  39. 05 May, 2017 1 commit
  41. 04 May, 2017 2 commits
  43. 02 May, 2017 1 commit
  45. 26 Apr, 2017 1 commit
  47. 25 Apr, 2017 2 commits
  49. 24 Apr, 2017 1 commit
  51. 11 Apr, 2017 3 commits
  53. 10 Apr, 2017 1 commit
  55. 07 Apr, 2017 2 commits
  57. 04 Apr, 2017 1 commit
  59. 31 Mar, 2017 2 commits
  61. 30 Mar, 2017 2 commits