1. 10 Jul, 2020 1 commit
  2. 22 Jun, 2020 1 commit
  3. 10 Jun, 2020 1 commit
  4. 28 May, 2020 1 commit
  5. 27 May, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Add syntax_only option to ParseRegExp · 5058c397
      Iain Ireland authored
      To ensure that regexp syntax errors are reported as early errors, SpiderMonkey calls ParseRegExp at parse time to validate that the regexp parses properly. This does not require the allocation of named capture information. We have a project underway to completely eliminate the allocation of GC things at parse time, which will require us to suppress the allocation of named capture information (or else jump through hoops to implement FixedArray as a non-GC thing).
      
      We can work around this in our shim layer -- for example, by setting a flag on the Factory shim that causes us to allocate dummy objects -- but it's much simpler to add an option to ParseRegExp.
      
      (Note: V8 currently does not treat regexp syntax errors as early errors. See https://bugs.chromium.org/p/v8/issues/detail?id=896.)
      
      Bug: v8:10406
      Change-Id: Ib5f0613a54509146e00f90cf61bda4bf03b03859
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207813
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67995}
      5058c397
  6. 19 Mar, 2020 3 commits
    • Iain Ireland's avatar
      Reland "[regexp] Rewrite error handling" · 560f2d8b
      Iain Ireland authored
      This is a reland of e80ca24c
      
      Original change's description:
      > [regexp] Rewrite error handling
      >
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      >
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      >
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      >
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      >
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      >
      > R=jgruber@chromium.org
      >
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66798}
      560f2d8b
    • Leszek Swirski's avatar
      Revert "[regexp] Rewrite error handling" · 2193f691
      Leszek Swirski authored
      This reverts commit e80ca24c.
      
      Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
      
      Original change's description:
      > [regexp] Rewrite error handling
      > 
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      > 
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      > 
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      > 
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      > 
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      > 
      > R=​jgruber@chromium.org
      > 
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      TBR=jgruber@chromium.org,iireland@mozilla.com
      
      Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10303
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66786}
      2193f691
    • Iain Ireland's avatar
      [regexp] Rewrite error handling · e80ca24c
      Iain Ireland authored
      This patch modifies irregexp's error handling. Instead of representing
      errors as C strings, they are represented as an enumeration value
      (RegExpError), and only converted to strings when throwing the error
      object in regexp.cc. This makes it significantly easier to integrate
      into SpiderMonkey. A few notes:
      
      1. Depending on whether the stack overflows during parsing or
         analysis, the stack overflow message can vary ("Stack overflow" or
         "Maximum call stack size exceeded"). I kept that behaviour in this
         patch, under the assumption that stack overflow messages are
         (sadly) the sorts of things that real world code ends up depending
         on.
      
      2. Depending on the point in code where the error was identified,
         invalid unicode escapes could be reported as "Invalid Unicode
         escape", "Invalid unicode escape", or "Invalid Unicode escape
         sequence". I fervently hope that nobody depends on the specific
         wording of a syntax error, so I standardized on the first one. (It
         was both the most common, and the most consistent with other
         "Invalid X escape" messages.)
      
      3. In addition to changing the representation, this patch also adds an
         error_pos field to RegExpParser and RegExpCompileData, which stores
         the position at which an error occurred. This is used by
         SpiderMonkey to provide more helpful messages about where a syntax
         error occurred in large regular expressions.
      
      4. This model is closer to V8's existing MessageTemplate
         infrastructure. I considered trying to integrate it more closely
         with MessageTemplate, but since one of our stated goals for this
         project was to make it easier to use irregexp outside of V8, I
         decided to hold off.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66784}
      e80ca24c
  7. 12 Mar, 2020 2 commits
    • Iain Ireland's avatar
      [regexp] Upstream small changes · a2b17a72
      Iain Ireland authored
      This is a grab-bag of small compatibility fixes to make it easier to
      import irregexp into SpiderMonkey. For changes where the commit
      message was longer than the change itself, it didn't seem worth
      opening a separate review.
      
      [regexp] Use uc16 in FilterOneByte
      
      SpiderMonkey uses char16_t instead of uint16_t for its two-byte
      strings. (This matches ICU. It looks like V8 considered making the
      same change, but decided against it: see
      https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately,
      irregexp is careful about only using uc16, so SpiderMonkey can just
      define uc16 = char16_t and *almost* everything works out. This patch
      fixes the single place in irregexp where that is not true.
      
      [regexp] Remove unreachable return
      
      The return statement at the end of
      RegExpParser::ParseClassCharacterEscape is unreachable, because every
      branch of the switch returns. This triggered static analysis errors in
      SpiderMonkey.
      
      [regexp] Remove trivial assertion
      
      The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail,
      because size_t is an unsigned type. This triggered static analysis
      warnings in SpiderMonkey.
      
      [regexp] Make RegExpStack constructor public
      
      In V8, the RegExpStack's private constructor is called from Isolate,
      which is a friend class. In SpiderMonkey, we use a wrapper around new
      to control where memory is allocated, so we need the RegExpStack
      constructor to be visible outside of Isolate.
      
      [regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated
      
      The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only
      place inside irregexp where HeapObject::Size is called. SpiderMonkey's
      heap-allocated objects live in arenas, and don't have a standardized
      way of finding the size. In this particular case it would be safe to
      hardcode a size of 0, but leaving HeapObject::Size undefined will
      ensure that SpiderMonkey doesn't silently do the wrong thing if
      somebody in V8 adds a new, more meaningful call to HeapObject::Size.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66676}
      a2b17a72
    • Iain Ireland's avatar
      [regexp] Use ZoneVector in parser and compiler · 5b44c169
      Iain Ireland authored
      For a variety of reasons related to OOM handling and custom
      allocators, SpiderMonkey wants to be able to see all memory
      allocations. To enforce this, we have a static analysis that verifies
      that we don't link in malloc/new/etc in unexpected places. One
      consequence of this is that we can't use STL containers without a
      custom allocator, because they call operator new internally.
      
      This is mostly not an issue in irregexp, which makes heavy use of zone
      allocation. The main exceptions are a handful of uses of std::vector
      in regexp-compiler.* and regexp-parser.*. If these vectors are
      converted to ZoneVectors, then our static analysis is satisfied.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I8b14a2eb54d3b20959e3fbe878f77effae124a2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091402Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66674}
      5b44c169
  8. 16 Oct, 2019 1 commit
  9. 24 Sep, 2019 1 commit
  10. 29 Aug, 2019 1 commit
  11. 09 Jul, 2019 1 commit
  12. 18 Jun, 2019 1 commit
  13. 17 Jun, 2019 2 commits
  14. 23 May, 2019 3 commits
  15. 22 May, 2019 1 commit
  16. 21 May, 2019 1 commit
  17. 06 May, 2019 1 commit
  18. 15 Feb, 2019 1 commit
  19. 08 Feb, 2019 1 commit
  20. 14 Nov, 2018 1 commit
  21. 08 Nov, 2018 1 commit
  22. 11 Oct, 2018 1 commit
  23. 19 Sep, 2018 1 commit
  24. 18 Sep, 2018 2 commits
  25. 11 Jul, 2018 1 commit
  26. 14 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored
      This reverts commit 0909dbe3.
      
      Reason for revert: Blocks roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1099143
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      > 
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
      
      Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7820
      Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  27. 13 Jun, 2018 1 commit
  28. 05 Jun, 2018 2 commits
  29. 09 Apr, 2018 1 commit
  30. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b