1. 25 Jul, 2018 1 commit
  2. 24 Jul, 2018 2 commits
  3. 20 Jul, 2018 1 commit
  4. 03 Jul, 2018 2 commits
  5. 21 May, 2018 1 commit
  6. 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
  7. 01 May, 2018 1 commit
  8. 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
  9. 08 Mar, 2018 1 commit
  10. 06 Mar, 2018 1 commit
  11. 01 Mar, 2018 2 commits
  12. 26 Feb, 2018 1 commit
  13. 21 Feb, 2018 1 commit
  14. 15 Feb, 2018 1 commit
  15. 06 Feb, 2018 1 commit
  16. 17 Jan, 2018 1 commit
  17. 11 Dec, 2017 1 commit
  18. 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
  19. 17 Nov, 2017 1 commit
  20. 31 Oct, 2017 1 commit
  21. 16 Oct, 2017 1 commit
  22. 13 Oct, 2017 2 commits
  23. 09 Oct, 2017 1 commit
  24. 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
  25. 26 Sep, 2017 1 commit
  26. 05 Sep, 2017 1 commit
  27. 30 Aug, 2017 1 commit
  28. 02 Aug, 2017 1 commit
  29. 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
  30. 25 Jun, 2017 1 commit
  31. 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
  32. 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
  33. 20 Jun, 2017 3 commits