Skip to content

V
V8
Switch branch/tag
  1. 28 May, 2020 1 commit
  3. 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
  5. 20 May, 2020 1 commit
  7. 19 May, 2020 2 commits
  9. 11 May, 2020 1 commit
  11. 29 Apr, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "[regexp] Limit the size of inlined choice nodes" · 10842cad
      Jakob Gruber authored 
      This is a reland of 6a0e7224

Original change's description:
> [regexp] Limit the size of inlined choice nodes
>
> Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge
> code objects. This effect can be further magnified through inlining,
> leading to exponential code growth in the size of the pattern.
>
> This CL is a (fairly hacky) way to avoid exponential growth. We
> recognize choice nodes with 'many' choices and disable inlining for
> them. In the future we should fix this properly, either by using the
> code size budget correctly, or by improving codegen for property
> escapes.
>
> Bug: v8:10441
> Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67433}

Tbr: yangguo@chromium.org
Bug: v8:10441
Change-Id: I9a16cc9e8248cb46d3d16a4e2d250968cc1b7b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172679Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67462}
      10842cad
  13. 28 Apr, 2020 5 commits
  15. 21 Apr, 2020 5 commits
    • Milad Farazmand's avatar
      [regexp] Add missing bracket to the s390 architecture · 3824775a
      Milad Farazmand authored 
      Change-Id: I5cf7c8eb00bb0cb3437ae8d82978543f3191e34a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158844Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67283}
      3824775a
    • Jakob Gruber's avatar
      [regexp] Consistent expectations for output registers · fe609139
      Jakob Gruber authored 
      ... between the interpreter and generated code.

Prior to this CL, pre- and post conditions on the output register
array differed between the interpreter and generated code.

Interpreter
Pre: `output` fits captures and temporary registers.
Post: None.

Generated code
Pre:  `output` fits capture registers.
Post: `output` is modified if and only if the match succeeded.

This CL changes the interpreter to match generated code pre- and
post conditions by allocating space for temporary registers inside
the interpreter.

Drive-by: Add MaxRegisterCount, RegistersForCaptureCount helpers.

Bug: chromium:1067270
Change-Id: I2900ef2f31207d817ec7ead3e0e2215b23b398f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135642
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67268}
      fe609139
    • Iain Ireland's avatar
      [regexp] Factor out PreprocessRegExp · 58ac66b7
      Iain Ireland authored 
      RegExpImpl::Compile does a number of transformations that require
directly manipulating the internal representation of the regexp. For
example, when matching a (non-sticky, non-anchored) regular
expression, the pattern must be wrapped in .* so that it can match
anywhere in the input.

In the interest of moving towards a cleaner division between irregexp
and the outside world, it makes sense to move this code into
RegExpCompiler.

R=jgruber@chromium.org

Bug: v8:10406
Change-Id: I6da251c91c0016914a51480f80bb46c337fd0b23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140246Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67262}
      58ac66b7
    • Jakob Gruber's avatar
      Reland "[protectors] Add use counters to track invalidations" · 6d392516
      Jakob Gruber authored 
      This is a reland of 52412058

Original change's description:
> [protectors] Add use counters to track invalidations
> 
> ... to make real world protector invalidations measurable.
> 
> Chromium CL: https://crrev.com/c/2149324
> 
> Drive-by: Add missing newline in protector tracing.
> Drive-by: Consistent naming for the regexp species protector.
> 
> Bug: v8:9496
> Change-Id: I3c7238aa8024e03ea9e89daf83345b8ec4f0d768
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149428
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67149}

Bug: v8:9496
Change-Id: I3c97bfa747e8429569eaa09ea909de73fc377efa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151363Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67261}
      6d392516
    • Iain Ireland's avatar
      [regexp] Hoist LoadCurrentCharacterImpl · 4536bb2e
      Iain Ireland authored 
      LoadCurrentCharacterImpl is implemented once in each of the eight
regexp-macro-assembler-<arch>.cc files. Aside from small differences
in comment wording, those eight implementations are identical. The
architecture-specific code for LoadCurrentCharacter is all in
LoadCurrentCharacterUnchecked.

This patch hoists the definition of LoadCurrentCharacterImpl into
NativeRegExpMacroAssembler and turns LoadCurrentCharacterUnchecked
into a virtual function.

Note: The arm64 version of LoadCurrentCharacterImpl contained the
following six-year-old comment, which I don't think is worth
preserving:

// TODO(pielan): Make sure long strings are caught before this, and
// not just asserted in debug mode.

R=jgruber@chromium.org

Bug: v8:10406
Change-Id: Ic81283ad3b618d6b06f4206fb77d30de617dccb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140003
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67260}
      4536bb2e
  17. 16 Apr, 2020 1 commit
  19. 15 Apr, 2020 1 commit
  21. 06 Apr, 2020 1 commit
  23. 20 Mar, 2020 1 commit
  25. 19 Mar, 2020 4 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
    • Emanuel Ziegler's avatar
      [wasm][mips] Save FP & PC when calling C functions · 38c3bd48
      Emanuel Ziegler authored 
      Ported changes from the following CLs to mips/mips64:
  - https://chromium-review.googlesource.com/c/v8/v8/+/2066964
  - https://chromium-review.googlesource.com/c/v8/v8/+/2071866
  - https://chromium-review.googlesource.com/c/v8/v8/+/2080242

This change is needed for profiling of Wasm code that calls C-function
to ignore the C-stack above the Wasm stack that otherwise couldn't be
parsed otherwise.

Bug: chromium:1045860
Change-Id: Ifdce5be6c5373714a67b3ce8d8c4f0a18f63b6fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082566Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66785}
      38c3bd48
    • 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
  27. 17 Mar, 2020 2 commits
    • Georgia Kouveli's avatar
      [arm64] Use BTI instructions for forward CFI · ea82d031
      Georgia Kouveli authored 
      Generate a BTI instruction at each target of an indirect branch
(BR/BLR). An indirect branch that doesn't jump to a BTI instruction
will generate an exception on a BTI-enabled core. On cores that do
not support the BTI extension, the BTI instruction is a NOP.

Targets of indirect branch instructions include, among other things,
function entrypoints, exception handlers and jump tables. Lazy deopt
exits can potentially be reached through an indirect branch when an
exception is thrown, so they also get an additional BTI instruction.

Bug: v8:10026
Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66751}
      ea82d031
    • Iain Ireland's avatar
      [regexp] Refactor to simplify embedding irregexp · 40d1b660
      Iain Ireland authored 
      Some code at the interface between irregexp and the rest of V8 uses
V8-specific APIs that are not used elsewhere in irregexp. For example,
only a handful of functions in irregexp call or are called from
generated code. When embedding irregexp into SpiderMonkey, these
functions are an obstacle, because they are dead code, but still have
to compile.

To simplify the process of embedding, this patch does two things:

1. It moves StringCharacterPosition out of irregexp and into
objects/string, renaming it "AddressOfCharacterAt".

2. It guards the following set of functions with
'#ifndef COMPILING_IRREGEXP_FOR_EXTERNAL_EMBEDDER':
- IrregexpInterpreter::MatchForCallFromJs
- NativeRegExpMacroAssembler::CheckStackGuardState
- NativeRegExpMacroAssembler::Match
- NativeRegExpMacroAssembler::Execute

This will have no effect in a V8 build, but can be defined by
SpiderMonkey or another embedder to omit the problematic functions.

In the future, if we attempt to make a cleaner separation between V8
and irregexp, these functions will be a good place to start defining
the API boundary.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I9f531a36e4f13440cafb0d0ade921f4c09f39c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097220Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66750}
      40d1b660
  29. 16 Mar, 2020 1 commit
  31. 12 Mar, 2020 4 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
    • Iain Ireland's avatar
      [regexp] Cache min/max-match for RegExpCapture/Group · 9b5141ca
      Iain Ireland authored 
      Unlike the other RegExpTree types, RegExpCapture and RegExpGroup don't
cache their min/maxMatch value. Instead, they compute it by recursing
on the min/maxMatch of the body node. In pathological cases, with
sufficiently small stacks, this can cause stack overflow. (In
SpiderMonkey's case, it was a worker on 32-bit x86.)

It's easy enough to just precompute the value when the body is set.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I4ba3d301d9a4a3f3c0cb94966148b747a4092d26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090192
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66673}
      9b5141ca
    • Iain Ireland's avatar
      [regexp] Remove function pointer in TextEmitPass · 73da478c
      Iain Ireland authored 
      TextEmitPass uses a function pointer to determine which pass to
call. This function pointer is only assigned inside TextEmitPass, and
can easily be eliminated by moving the calls to each possible target
inside the switch statement that assigns the function pointer.

I made this change because SpiderMonkey uses a static analysis pass to
verify that everything is rooted properly across calls that might GC,
and that analysis is conservative when calling function pointers. We
can white-list function pointers that are known to be safe, but the
code being called through this function pointer is complex enough
(and the function pointer is unnecessary enough) that it seemed best
to just remove the function pointer entirely.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I5fbb0df290a2288c4d3db6d43a563385337162ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091398
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66672}
      73da478c
  33. 10 Mar, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Fix and unify non-unicode case-folding algorithms · 3fab9d05
      Iain Ireland authored 
      Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a
case-folding algorithm that doesn't quite match the Unicode
definition. There are two places in irregexp that need to do
case-folding. Prior to this patch, neither of them quite matched the
spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch).

This patch implements the "Canonicalize" algorithm in
src/regexp/special-case.h, and uses it in the relevant places. It
replaces special-case logic around upper-casing / ASCII characters
with the following approach:

1. For most characters, calling UnicodeSet::closeOver on a set
   containing that character will produce the correct set of
   case-insensitive matches.

2. For a small handful of characters (like the sharp S that prompted
   this change), UnicodeSet::closeOver will include some characters
   that should be omitted. For example, although closeOver('ß') =
   "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß'
   canonicalizes to itself, and should not match 'ẞ'. In these cases,
   we can skip the closeOver entirely, because it will never add an
   equivalent character. These characters are in the IgnoreSet.

3. For an even smaller handful of characters, UnicodeSet::closeOver
   will produce some characters that should be omitted, but also some
   characters that should be included. For example, closeOver('k') =
   "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN
   SIGN should not match either of the other two (step 3.g). To handle
   this, we put such characters in the SpecialAddSet. In these cases,
   we closeOver the original character, but filter out the results
   that do not have the same canonical value.

The computation of IgnoreSet and SpecialAddSet happens at build time,
using the pre-existing gen-regexp-special-case.cc step.

R=jgruber@chromium.org

Bug: v8:10248
Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858Reviewed-by: 's avatarFrank Tang <ftang@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66641}
      3fab9d05
  35. 03 Mar, 2020 1 commit
  37. 02 Mar, 2020 3 commits
  39. 28 Feb, 2020 1 commit
  41. 27 Feb, 2020 2 commits
    • Milad Farazmand's avatar
      PPC/s390: [wasm] Save FP & PC when calling C functions · 242d58e3
      Milad Farazmand authored 
      Port 6cd28b52

Original Commit Message:

    Added implementations for ia32, arm, arm64.

    mips/mips64 will be committed in separate CL once the build is green
    again in order not to stall this CL with the supported architectures.

    compilation by using alternative temp register for x64.

    macro assemblers.

R=ecmziegler@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ib08e31dfa11f0254c7888ce17dd27e7d0154c752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078898Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66490}
      242d58e3
    • Emanuel Ziegler's avatar
      [wasm] Save FP & PC when calling C functions · 6cd28b52
      Emanuel Ziegler authored 
      Added implementations for ia32, arm, arm64.

mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.

Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.

Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.

R=clemensb@chromium.org
R=petermarshall@chromium.org
R=jgruber@chromium.org

Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
      6cd28b52