Skip to content

V
V8
Switch branch/tag
  1. 25 Jul, 2018 1 commit
  3. 24 Jul, 2018 2 commits
  5. 20 Jul, 2018 1 commit
  7. 03 Jul, 2018 2 commits
  9. 21 May, 2018 1 commit
  11. 02 May, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[parser] Slice the source string where possible" · 18bc2856
      Leszek Swirski authored 
      This reverts commit 2df5e7a7.

Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805

Original change's description:
> [parser] Slice the source string where possible
> 
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
> 
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
> 
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}

TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org

Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
      18bc2856
  13. 01 May, 2018 1 commit
  15. 15 Mar, 2018 2 commits
    • Sathya Gunasekaran's avatar
      [numeric separator] Simplify error handling · e77eebfe
      Sathya Gunasekaran authored 
      Pointing to the exact spot of the incorrect numeric separator seems
clearer both in terms of the error itself, and the resulting code in
scanner because we don't have to keep track of the start position.

Previously, the error was:
  ➜ ./out.gn/x64.release/d8 --harmony-numeric-separator -e '0x1__1'
  unnamed:1: SyntaxError: Only one underscore is allowed as numeric separator
  0x1__1
  ^^^^
  SyntaxError: Only one underscore is allowed as numeric separator

Now, the error is:
  ➜ ./out.gn/x64.release/d8 --harmony-numeric-separator -e '0x1__1'
  unnamed:1: SyntaxError: Only one underscore is allowed as numeric separator
  0x1__1
      ^
  SyntaxError: Only one underscore is allowed as numeric separator


Bug: v8:7317
Change-Id: I7df1b39816e51a97234da6ed0fca1bf8c0223c3e
Reviewed-on: https://chromium-review.googlesource.com/962241
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51950}
      e77eebfe
    • Sathya Gunasekaran's avatar
      [numeric separator] Ban implicit octal support · 9c983910
      Sathya Gunasekaran authored 
      Bug: v8:7317
Change-Id: I20fb706c05852668a5a6ae8b69c150ae2e6b2f65
Reviewed-on: https://chromium-review.googlesource.com/960901Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51943}
      9c983910
  17. 08 Mar, 2018 1 commit
  19. 06 Mar, 2018 1 commit
  21. 01 Mar, 2018 2 commits
  23. 26 Feb, 2018 1 commit
  25. 21 Feb, 2018 1 commit
  27. 15 Feb, 2018 1 commit
  29. 06 Feb, 2018 1 commit
  31. 17 Jan, 2018 1 commit
  33. 11 Dec, 2017 1 commit
  35. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored 
      This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.

Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.

Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters

Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.

BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  37. 17 Nov, 2017 1 commit
  39. 31 Oct, 2017 1 commit
  41. 16 Oct, 2017 1 commit
  43. 13 Oct, 2017 2 commits
  45. 09 Oct, 2017 1 commit
  47. 02 Oct, 2017 1 commit
    • Mathias Bynens's avatar
      [parser] Add use counter for U+2028 & U+2029 · d3c98121
      Mathias Bynens authored 
      The context is the following proposal to make JSON a subset of
JavaScript: https://github.com/tc39/proposal-json-superset

There’s interest in performing a side investigation to answer the
question of what would happen if we stopped treating U+2028 and U+2029
as `LineTerminator`s *entirely*. (Note that this is separate from the
proposal, which just changes how these characters are handled in
ECMAScript strings.) This is technically a breaking change, and IMHO it
would be wonderful if we could get away with it, but no one really has
any data on whether or not we could. Adding this use counter lets us get
that data.

BUG=v8:6827

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
Reviewed-on: https://chromium-review.googlesource.com/693155
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48260}
      d3c98121
  49. 26 Sep, 2017 1 commit
  51. 05 Sep, 2017 1 commit
  53. 30 Aug, 2017 1 commit
  55. 02 Aug, 2017 1 commit
  57. 26 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · 777da354
      hans authored 
      This is towards closing the perf gap between the MSVC build (which uses link-
time optimization) and Clang (where LTO isn't ready on Windows yet). We did
a study (see bug) to see which non-inlined functions are hit a lot during render
start-up, and which would be inlined during LTO. This should benefit performance
in all builds which currently don't use LTO (Android, Linux, Mac) as well as
the Win/Clang build.

The binary size of chrome_child.dll increases by 2KB with this.

BUG=chromium:728324
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng

Review-Url: https://codereview.chromium.org/2950993002
Cr-Commit-Position: refs/heads/master@{#46229}
      777da354
  59. 25 Jun, 2017 1 commit
  61. 23 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · d00d52be
      hans authored 
      This is towards closing the perf gap between the MSVC build (which uses link-
time optimization) and Clang (where LTO isn't ready on Windows yet). We did
a study (see bug) to see which non-inlined functions are hit a lot during render
start-up, and which would be inlined during LTO. This should benefit performance
in all builds which currently don't use LTO (Android, Linux, Mac) as well as
the Win/Clang build.

The binary size of chrome_child.dll increases by 2KB with this.

BUG=chromium:728324

Review-Url: https://codereview.chromium.org/2950993002
Cr-Commit-Position: refs/heads/master@{#46191}
      d00d52be
  63. 21 Jun, 2017 1 commit
    • bakkot's avatar
      Reland "[parser] Forbid \08 in strict strings" · 76078e14
      bakkot authored 
      (Reland: NeedsManualRebaseline'd newly-fixed layout test in Chromium.)

This was never legal; the spec only allows '\0' in strict-mode strings
or templates when not followed by a decimal digit. Previously we were
only enforcing that it not be followed by an _octal_ digit.

This was already fixed for numeric literals, but not for escape
sequences in strings.

BUG=v8:6504

Review-Url: https://codereview.chromium.org/2948903002
Cr-Commit-Position: refs/heads/master@{#46106}
      76078e14
  65. 20 Jun, 2017 3 commits