Skip to content

V
V8
Switch branch/tag
  1. 06 Nov, 2017 1 commit
  3. 31 Oct, 2017 1 commit
    • Mathias Bynens's avatar
      [parser] Improve error message for `import()` · dbcea115
      Mathias Bynens authored 
      Currently, dynamic `import()` throws the following SyntaxError when
used without a specifier:

    > import();
    < Uncaught SyntaxError: Unexpected token )

From the error message, it seems this the result of the code snippet
being seen as static `import` followed by parens, as opposed to
`import()` with no specifier.

This patch makes this error message more clear:

    > import();
    < SyntaxError: import() requires a specifier

BUG=v8:7020,v8:6513

Change-Id: I3519dfd0029f38d23da858a5499f1d226e794935
Reviewed-on: https://chromium-review.googlesource.com/747141Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49058}
      dbcea115
  5. 27 Oct, 2017 1 commit
  7. 25 Oct, 2017 1 commit
  9. 11 Oct, 2017 1 commit
  11. 10 Oct, 2017 1 commit
  13. 09 Oct, 2017 1 commit
  15. 05 Oct, 2017 1 commit
  17. 29 Sep, 2017 1 commit
  19. 26 Sep, 2017 4 commits
  21. 15 Sep, 2017 1 commit
  23. 25 Aug, 2017 1 commit
  25. 14 Aug, 2017 1 commit
  27. 08 Aug, 2017 1 commit
    • Adam Klein's avatar
      Throw errors when assigning to const variables inside `with` · a9846ad4
      Adam Klein authored 
      This code appears to have been wrong forever, as it only
threw in strict mode (presumably predating ES2015 const).

In order to get exactly the right behavior, special
handling of sloppy named function expressions is required.
Rather than polluting PropertyAttributes with another
dummy value, this CL simply adds a bool output argument
to Context::Lookup to indicate that case.

Bug: v8:6677
Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
Reviewed-on: https://chromium-review.googlesource.com/602690Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47207}
      a9846ad4
  29. 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
  31. 25 Jul, 2017 1 commit
  33. 20 Jul, 2017 1 commit
  35. 19 Jul, 2017 1 commit
    • Daniel Ehrenberg's avatar
      [parser] Prohibit async functions and generators in invalid contexts · ee15703e
      Daniel Ehrenberg authored 
      Async functions and generator declarations are only permitted as
StatementListItems, not as ExpressionStatements, and therefore not
as the entire body of an if statement, etc. Previously, they were
incorrectly permitted. However, ChakraCore and SpiderMonkey seem
to ban them in this context, and the feature was introduced relatively
recently, so it is likely to be web-compatible to ship the prohibition.

This patch also unifies the error message wording of async functions
and generators to ordinary functions, explaining more clearly what
the issue is.

Bug: v8:4483
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I31ed7818d6ab3e7e325031bfabb933dbf4512143
Reviewed-on: https://chromium-review.googlesource.com/568979
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46770}
      ee15703e
  37. 14 Jul, 2017 1 commit
  39. 10 Jul, 2017 1 commit
  41. 06 Jul, 2017 1 commit
  43. 16 Jun, 2017 1 commit
  45. 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
  47. 12 Jun, 2017 1 commit
  49. 19 May, 2017 1 commit
  51. 04 May, 2017 2 commits
  53. 24 Apr, 2017 1 commit
  55. 19 Apr, 2017 1 commit
  57. 18 Apr, 2017 2 commits
  59. 14 Apr, 2017 1 commit
  61. 12 Apr, 2017 1 commit
  63. 06 Apr, 2017 1 commit
  65. 29 Mar, 2017 1 commit
  67. 28 Mar, 2017 2 commits
    • jgruber's avatar
      [regexp] Named capture support for string replacements · 9403edfa
      jgruber authored 
      This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is not callable.

Named captures can be referenced from replacement strings by using the
"$<name>" syntax. A couple of examples:

let re = /(?<fst>.)(?<snd>.)/u;
"abcd".replace(re, "$<snd>$<fst>")  // "bacd"
"abcd".replace(re, "$2$1")     // "bacd" (numbered refs work as always)
"abcd".replace(re, "$<snd")    // SyntaxError (unterminated named ref)
"abcd".replace(re, "$<42$1>")  // "cd" (invalid name)
"abcd".replace(re, "$<thd>")   // "cd" (non-existent name)
"abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>")  // "cd" (non-matched capture)

Support is currently behind the --harmony-regexp-named-captures flag.

BUG=v8:5437

Review-Url: https://codereview.chromium.org/2775303002
Cr-Original-Commit-Position: refs/heads/master@{#44171}
Committed: https://chromium.googlesource.com/v8/v8/+/17f13863b64b25eccf565e0aa9c4c441f0562b84
Review-Url: https://codereview.chromium.org/2775303002
Cr-Commit-Position: refs/heads/master@{#44182}
      9403edfa
    • jgruber's avatar
      Revert of [regexp] Named capture support for string replacements (patchset #5... · 34ffdd62
      jgruber authored 
      Revert of [regexp] Named capture support for string replacements (patchset #5 id:80001 of https://codereview.chromium.org/2775303002/ )

Reason for revert:
Invalid DCHECKs for non-matched groups.

Original issue's description:
> [regexp] Named capture support for string replacements
>
> This implements support for named captures in
> RegExp.prototype[@@replace] for when the replaceValue is not callable.
>
> Named captures can be referenced from replacement strings by using the
> "$<name>" syntax. A couple of examples:
>
> let re = /(?<fst>.)(?<snd>.)/u;
> "abcd".replace(re, "$<snd>$<fst>")  // "bacd"
> "abcd".replace(re, "$2$1")     // "bacd" (numbered refs work as always)
> "abcd".replace(re, "$<snd")    // SyntaxError (unterminated named ref)
> "abcd".replace(re, "$<42$1>")  // "cd" (invalid name)
> "abcd".replace(re, "$<thd>")   // "cd" (non-existent name)
> "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>")  // "cd" (non-matched capture)
>
> Support is currently behind the --harmony-regexp-named-captures flag.
>
> BUG=v8:5437
>
> Review-Url: https://codereview.chromium.org/2775303002
> Cr-Commit-Position: refs/heads/master@{#44171}
> Committed: https://chromium.googlesource.com/v8/v8/+/17f13863b64b25eccf565e0aa9c4c441f0562b84

TBR=yangguo@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5437

Review-Url: https://codereview.chromium.org/2776293003
Cr-Commit-Position: refs/heads/master@{#44180}
      34ffdd62