- 06 Sep, 2022 1 commit
-
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=jgruber@chromium.org Bug: v8:12887 Change-Id: Ide7272de6a59e8324f19d4f52053737b56a380d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3875083 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#82989}
-
- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 29 Sep, 2021 1 commit
-
-
Jakob Gruber authored
.. and refactor js-regexp.h. - Hide the generic DataAt/SetDataAt accessors and replace them by dedicated accessors. Use the common lower_case naming scheme for these. - Shuffle around definitions in js-regexp.h s.t. they are in a meaningful order. - Dedupe the source/flags accessors - these fields are stored both on the instance and on the data array. We keep only accessors for the instance. Previously, these were disambiguated through naming oddities (e.g. Pattern() returned data->source). Change-Id: I3d53c8b095f0d59621ff779608438f7fa5e8c92a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193534 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#77138}
-
- 23 Sep, 2021 1 commit
-
-
Jakob Gruber authored
The argument is no longer in use. Bug: v8:11382 Change-Id: I7febc7fe7ef17ae462c700f0dba3ca1beade3021 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173681 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#77017}
-
- 19 Aug, 2021 2 commits
-
-
Jakob Gruber authored
.. and decrease the include-ball size. Change-Id: Id35358a6882156f6684475b7f0b0193f8ca5eaf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103313 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76386}
-
Jakob Gruber authored
The JSRegExp heap object should not be the source of truth for regexp flags, which are also relevant in places that don't need or want to care about the heap object layout (e.g.: the regexp parser). Introduce RegExpFlags as a new source of truth, and base everything else on these flags. As a first change, remove the js-regexp.h dependency from the regexp parser. Other files in src/regexp/ should be updated in follow-up work. Change-Id: Id9a6706c7f09e93f743b08b647b211d0cb0b9c76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103306Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76379}
-
- 18 Aug, 2021 2 commits
-
-
Jakob Gruber authored
.. instead of a FlatStringReader. This is in preparation for reusing the regexp parser directly from the JS parser, which uses different string types (AstRawString instead of heap Strings). Drive-by: Hide parser internals in the .cc file. Bug: v8:896 Change-Id: I06bd08f2ef5fd7a5e9812c123d88b89cacf5d864 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101488 Commit-Queue: Patrick Thier <pthier@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76365}
-
Jakob Gruber authored
In follow-up work, the parser will be refactored to take the input as raw char arrays instead of a FlatStringReader s.t. it can be reused by the V8 parser (which has AstRawStrings instead of Strings). Bug: v8:896 Change-Id: I0e0bda4b34bc23b8bc427ddf3f9516081c42bb8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099947Reviewed-by: Patrick Thier <pthier@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76359}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 17 Jun, 2021 1 commit
-
-
Igor Sheludko authored
Bug: v8:11880 Change-Id: Idf23521d6cb1885922f92e1050937daa2d29acd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968409Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75225}
-
- 11 Feb, 2021 1 commit
-
-
Jakob Gruber authored
V8 implements a fast-path for RegExp.prototype.split which diverges from the spec: instead of creating a new sticky regexp instance `splitter` and running it in a loop, we reuse the existing non-sticky regexp without looping through each character. This works fine in most cases, but we run into issues when matching at the very end of the string. According to the spec, matches at the end of the string are impossible in @@split, but in our fast-path implementation they can happen. The obvious fix would be to remove our fast-path but this comes with high performance costs. The fix implemented in this CL adds a special flag to `exec` s.t. matches at the end of the string can be treated as failures. This is only relevant for @@split. Bug: chromium:1075514 Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#72644}
-
- 12 Jan, 2021 1 commit
-
-
Camillo Bruni authored
Make sure gcmole detects issue in DisallowGarbageCollection scopes. DisallowGarbageCollection is widely used in the codebase to document code that doesn't allocate. However, this has the rather unexpected side-effect that gcmole is not run when such a scope is active. This CL changes the default behavior of gcmole to run even with DisallowGarbageCollection scopes present. This will give us the best results of both worlds, dynamic checks by the fuzzer, and static analysis by gcmole. To allow crazy local raw pointer operations there is a new DisableGCMole scope that explicitly disables gcmole. Change-Id: I0a78fb3b4ceaad35be9bcf7293d917a41f90c91f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615419Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72039}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 30 Oct, 2020 1 commit
-
-
Martin Bidlingmaier authored
This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l) that forces execution in linear time. These regexps are handled by the experimental engine. If the experimental engine cannot handle the pattern, an exception is thrown on creation of the regexp. The commit also adds a new global V8 flag and changes an existing one: * --enable-experimental-engine, which turns on recognition of the RegExp 'l' flag. Previously this flag also caused all supported regexps to be executed by the experimental engine; this is not the case anymore. * --default-to-experimental-regexp-engine takes over the previous semantics of --enable-experimental-regexp-engine: We execute all supported regexps with the experimental engine. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Martin Bidlingmaier <mbid@google.com> Cr-Commit-Position: refs/heads/master@{#70892}
-
- 19 Oct, 2020 1 commit
-
-
Martin Bidlingmaier authored
The problem was that a raw regexp value was handlified to account for gc, but then afterwards we used the initial regexp value again instead of the handle. This resulted in memory violations if the gc decided to move the regexp object. Bug: chrome:1139304,v8:10765,v8:11021 Change-Id: Ib1c31ae4a960523c9939619bcca9606dbb507c81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484771Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Martin Bidlingmaier <mbid@google.com> Cr-Commit-Position: refs/heads/master@{#70605}
-
- 14 Oct, 2020 1 commit
-
-
Martin Bidlingmaier authored
We fall back from irregexp to the experimental engine if a backtrack limit is exceeded and the experimental engine can handle the regexp. The feature can be turned on with a boolean flag, and an uint-valued flag controls the default backtrack limit. For regexps that are constructed with an explicit backtrack limit (API, %NewRegExpWithBacktrackLimit), we choose the lower of the explicit and default backtrack limits. The default backtrack limit does not apply to regexps that can't be handled by the experimental engine, and for such regexps an explicitly specified backtrack limit is handled as before by returning null if we exceed it. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70500}
-
- 07 Oct, 2020 1 commit
-
-
Martin Bidlingmaier authored
No surprises; very much based on interrupt handling in the irregexp interpreter. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I2353cac4639a494362b8dfdf9507985fb6298c0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452710Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Martin Bidlingmaier <mbid@google.com> Cr-Commit-Position: refs/heads/master@{#70370}
-
- 23 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
The m (multiline) and s (dotall) flags just needed to be marked as allowed; the required logic was already in the regexp parser. A regexp /<x>/ without the y (sticky) flag is equivalent to the sticky regexp /.*?<x>/y. The interpreter now assumes that every regexp is sticky, and the compiler appends a preamble corresponding to /.*?/ before non-sticky regexps. To reuse existing code for compiling this preamble, the logic for each kind of quantifier is now in a separate function and called from VisitQuantifier and for the preamble. The commit also includes some improvements/fixes for character ranges: - Empty character ranges/disjunctions should never match, but before this commit they would *always* match. - The check of the range bounds in CanBeHandledVisitor was unncessary; without the unicode flag this can't be a range that can't be specified in 2-byte codepoints, and once we support unicode we simply support all codepoints. - The capacity of the list containing the complementary intervals of a character range is now calculated more accurately. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I71a0e07279b4e1140c0ed1651b3714200c801de9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404766 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70082}
-
- 16 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
This commit adds support for capture groups (as in e.g. /x(123|abc)y/) in the experimental regexp engine. Now every InterpreterThread owns a register array containing (sub)match boundaries. There is a new instruction to record the current input index in some register. Submatches in quantifier bodies should be reported only if they occur during the last repetition. Thus we reset those registers before attempting to match the body of a quantifier. This is implemented with another new instruction. Because of concerns for the growing sizeof the NfaInterpreter object (which is allocated on the stack), this commit replaces the `SmallVector` members of the NfaInterpreter with zone-allocated arrays. Register arrays, which for a fixed regexp are all the same size, are allocated with a RecyclingZoneAllocator for cheap memory reclamation via a linked list of equally-sized free blocks. Possible optimizations for management of register array memory: 1. If there are few register per thread, then it is likely faster to store them inline in the InterpreterThread struct. 2. re2 implements copy-on-write: InterpreterThreads can share the same register array. If a thread attempts to write to shared register array, the register array is cloned first. 3. The register at index 1 contains the end of the match; this is only written to right before an ACCEPT statement. We could make ACCEPT equivalent to what's currently CAPTURE 1 followed by ACCEPT. We could then save the memory for register 1 for threads that haven't finished yet. This is particularly interesting if now optimization 1 kicks in. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I2c0503206ce331e13ac9912945bb66736d740197 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69929}
-
- 08 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
Sometimes the parser throws away redundant parts of the AST while parsing. For example, the regexp /(?:(?=(f)o))?f/ is (almost) equivalent to just /f/ because the optional block (...)? is zero-length. The parser notices this and returns the same tree as for /f/. However, there is a capture inside the (...)? block (which is never recorded because the quantifier containing it can only match zero-width, which is considered failure), so in this case it doesn't suffice to check that the regexp AST doesn't contain captures. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I6145849d95b3522a397eadd2bae63d1d8e880f28 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397896Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Martin Bidlingmaier <mbid@google.com> Cr-Commit-Position: refs/heads/master@{#69733}
-
- 01 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
Bug: v8:10765 Change-Id: I49e425d861d900ab66b6f7801cddec8a7175ac03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385462 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69637}
-
- 31 Aug, 2020 1 commit
-
-
Martin Bidlingmaier authored
This CL adds support for disjunctions and some quantification in EXPERIMENTAL regexp patterns. It is implemented using a new bytecode format and an NFA-based breadth-first interpreter. R=jgruber@chromium.org Bug: v8:10765 Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69621}
-
- 18 Aug, 2020 1 commit
-
-
Martin Bidlingmaier authored
This adds the new JsRegExp::Type EXPERIMENTAL, which should eventually be implemented with the algorithm based on automata. Currently the new engine deals with plain search strings only, i.e. regexps that do not contain operators or escape sequences. R=jgruber@chromium.org Bug: v8:10765 Change-Id: I6a10d9cdf4605d219dbe7cc1989df3bfa7349ff8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339094Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69442}
-