- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Icc60fdbf247ec05f9b5688b3d2d73d4fed06ea89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289770 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68784}
-
- 22 Jun, 2020 1 commit
-
-
Dan Elphick authored
This changes black/white list to block/allow list. Bug: v8:10619 Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68464}
-
- 10 Jun, 2020 1 commit
-
-
Jakob Gruber authored
Prior to this change, uc16 was typedef'd to (unsigned) uint16_t while uc32 was typedef'd to (signed) int32_t. For consistency, and to avoid unexpected behavior around signed/unsigned comparisons, this changes uc32 to the unsigned uint32_t type. As part of this change, old-style error passing (return -1, check for negative return values) was updated to use named error values. Bug: v8:10568 Change-Id: I8524e66ee20e8738749cd34c4fe82c14e885dcb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235533Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68282}
-
- 28 May, 2020 1 commit
-
-
Iain Ireland authored
Embarrassingly, while integrating VerifyRegExpSyntax into SpiderMonkey, I realized that I had refactored away the RegExpCompileData* argument, which is necessary for emitting error messages when parsing fails. Bug: v8:10406 Change-Id: Iaa8cd1f944bbf058ccc03c052b5ec0563b7c2e99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219415Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68033}
-
- 27 May, 2020 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67995}
-
- 19 Mar, 2020 3 commits
-
-
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: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66798}
-
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: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66786}
-
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: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66784}
-
- 12 Mar, 2020 2 commits
-
-
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: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66676}
-
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: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66674}
-
- 16 Oct, 2019 1 commit
-
-
Jakob Gruber authored
Named capture properties on the groups object should be ordered by the capture index (and not alpha-sorted). This was accidentally broken in https://crrev.com/c/1687413. Bug: v8:9822,v8:9423 Change-Id: Iac6f866f077a1b7ce557ba47e8ba5d7e7014b3ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864829 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64306}
-
- 24 Sep, 2019 1 commit
-
-
Jakob Gruber authored
This extends suppressions to also handle excess zone allocations in the parser. Bug: chromium:1002510 Change-Id: Id418564d244ed618703e62260de31a6b1a2842f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821459 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63948}
-
- 29 Aug, 2019 1 commit
-
-
Patrick Thier authored
The code fields in a JSRegExp object now either contain irregexp compiled code or a trampoline to the interpreter. This way the code can be executed without explicitly checking if the regexp shall be interpreted or executed natively. In case of interpreted regexp the generated bytecode is now stored in its own fields instead of the code fields for Latin1 and UC16 respectively. The signatures of the jitted irregexp match and the regexp interpreter have been equalized. Bug: v8:9516 Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63457}
-
- 09 Jul, 2019 1 commit
-
-
Ana Pesko authored
This CL changes the use of a ZoneList for keeping track of named captures in a regular expression to a ZoneMap, to optimize finding the named capture in the structure. Bug: v8:9423 Change-Id: Id952ac8f86c1dc5d69a3b0251ff724d1509879dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687413 Commit-Queue: Ana Pesko <anapesko@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62601}
-
- 18 Jun, 2019 1 commit
-
-
Jakob Gruber authored
This CL renames jsregexp.{h,cc} to regexp.{h,cc}, hides all non-public functions of RegExpImpl in the .cc file, and renames the public parts of RegExpImpl to just RegExp. Include directives from outside the src/regexp directory are limited to regexp.h, regexp-stack.h, and regexp-utils.h. We also expose all result codes that can be returned by irregexp code (including RETRY) on the public header since they are needed elsewhere, e.g. in builtins. Bug: v8:9359 Change-Id: Iae1a01ac9f6e1e4dc168f3fbe8fe8679cb6b1259 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662297Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62240}
-
- 17 Jun, 2019 2 commits
-
-
Jakob Gruber authored
RegExp assertions (e.g.: '^', '$', '\b', ...) sequences have certain properties that this rewriter exploits: 1. They are zero-width and order-independent, thus one can remove all duplicate assertions. 2. If a subsequence is guaranteed to fail, the entire sequence fails. Any sequence always known to fail (e.g. containing both '\b' and '\B') can be rewritten to a single node that triggers failure. This CL generalizes the previous optimization for repeated assertions to be order-independent, i.e. assertions only have to be in the same sequence but not next to each other. Bug: v8:6515, v8:6126 Change-Id: I3f92f081ce8a55ad8c34c269a09a6686e3b008f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657925 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62201}
-
Jakob Gruber authored
Bug: v8:9359 Change-Id: I06a4ccc53abff25237a1113774a0b17bdf861c86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658157Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62198}
-
- 23 May, 2019 3 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
Sigurd Schneider authored
The type of the argument makes it clear what we're internalizing, and this allows us to choose either one based on a template parameter. Change-Id: I6d7865e7fdef364f6cf10ff9267034df182d7539 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624212 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61765}
-
- 22 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I79e0553e8a0d6dac2aa16b94a6c0e05b6ccde4a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621934 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61725}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I9bcf2694b449f79cdbe03f5fde59cb21b8cad418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619758 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61676}
-
- 06 May, 2019 1 commit
-
-
Michael Achenbach authored
Error messages are unspecified in JavaScript and occasional small differences in the compared configurations lead to an unjustified maintenance burden of correctness-fuzzing issues. This CL replaces most error messages with a fixed suppression message during correctness fuzzing (behind a flag). The flag covering all extra behavior for correctness fuzzing is now renamed to --correctness-fuzzer-suppressions. Bug: chromium:958668,chromium:946476 Change-Id: Iba1197f765138a962d5bbb176730322e5a411707 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594730 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61249}
-
- 15 Feb, 2019 1 commit
-
-
Jakob Kummerow authored
This takes heap-inl.h out of the "Giant Include Cluster". Naturally, that means adding a bunch of explicit includes in a bunch of places that relied on transitively including them before. As of this patch, no header file outside src/heap/ includes heap-inl.h. Bug: v8:8562,v8:8499 Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1459659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59617}
-
- 08 Feb, 2019 1 commit
-
-
Seth Brenith authored
When creating the results object for an exec call, V8 is calling into a runtime helper once per named capture group. It can instead create that object without any runtime calls, using existing CSA helpers. The only additional cost of this approach is that it internalizes the capture group names at regex compilation time, even if the script never calls exec on that regex. Bug: v8:6914 Change-Id: I58975b8d7aea05f8c67ae087608715099f62fc48 Reviewed-on: https://chromium-review.googlesource.com/c/1454268Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59470}
-
- 14 Nov, 2018 1 commit
-
-
Leszek Swirski authored
Moves the unicode predicate cache tables out of the unicode cache, and turns them into generic predicates in char-predicates.h which use static constexpr tables. This drops the per-isolate cost of unicode caches, and removes the need for accessing the unicode cache from most files. It does remove the mutability of the cache, which means that there may be regressions when parsing non-ASCII identifiers. Most likely the benefits to ASCII identifiers/keywords will outweigh any non-ASCII costs. Change-Id: I9a7a8b7c9b22d3e9ede824ab4e27f133ce20a399 Reviewed-on: https://chromium-review.googlesource.com/c/1335564Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#57506}
-
- 08 Nov, 2018 1 commit
-
-
Frank Tang authored
Requires ICU 63 or above be used when building v8 1. Remove unneeded #include of icu header files 2. Remove code inside "#if U_ICU_VERSION_MAJOR_NUM < x" block where x is 63 or smaller. Bug: v8:8401 v8:5751 Change-Id: I908b0d7d174df53d4296580fe7150417322b0b21 Reviewed-on: https://chromium-review.googlesource.com/c/1314112Reviewed-by: Jungshik Shin <jshin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#57341}
-
- 11 Oct, 2018 1 commit
-
-
Jakob Kummerow authored
The primary purpose of this is to untangle a circular dependency objects.h -> handles.h -> objects.h. Most compilation units only need message-template.h, without the rest of messages.h. Bonus: change the enum to an enum class for improved type safety. Bug: v8:3770 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I8102c55197a450811de2588a68a08e7f99ea6b9e Reviewed-on: https://chromium-review.googlesource.com/c/1272193 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#56583}
-
- 19 Sep, 2018 1 commit
-
-
Yang Guo authored
This is a reland of f4c14fd9 TBR=jgruber@chromium.org Original change's description: > [regexp] implement regexp property sequence proposal > > Also-By: mathias@chromium.org > Bug: v8:7467 > Change-Id: I9fd6e61f4da1097c2375f671b4801e9730f792c4 > Reviewed-on: https://chromium-review.googlesource.com/1227974 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Mathias Bynens <mathias@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55991} Bug: v8:7467 Change-Id: If07137dea5a8ea42dbff1d749d997eb4ae055d80 Reviewed-on: https://chromium-review.googlesource.com/1232634Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56017}
-
- 18 Sep, 2018 2 commits
-
-
Leszek Swirski authored
This reverts commit f4c14fd9. Reason for revert: Breaks noi18n build Original change's description: > [regexp] implement regexp property sequence proposal > > Also-By: mathias@chromium.org > Bug: v8:7467 > Change-Id: I9fd6e61f4da1097c2375f671b4801e9730f792c4 > Reviewed-on: https://chromium-review.googlesource.com/1227974 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Mathias Bynens <mathias@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55991} TBR=yangguo@chromium.org,jgruber@chromium.org,mathias@chromium.org Change-Id: I10c67ad3ade35af920d32a7eea8ae0297677fa07 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7467 Reviewed-on: https://chromium-review.googlesource.com/1230137Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#55996}
-
Yang Guo authored
Also-By: mathias@chromium.org Bug: v8:7467 Change-Id: I9fd6e61f4da1097c2375f671b4801e9730f792c4 Reviewed-on: https://chromium-review.googlesource.com/1227974 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#55991}
-
- 11 Jul, 2018 1 commit
-
-
Jungshik Shin authored
See https://chromium-review.googlesource.com/c/chromium/deps/icu/+/1128503 for ICU changes. Fix tests for ICU 61/Unicode 11/CLDR 33.1 * Update mjsunit/harmony/regexp-property-script-extensions.js per ScriptExtensions.txt in Unicode 11 * Update mjsunit/intl-numberformat-formattoparts.js for CLDR 33.1 * Mark an invalid Mozilla test (Georgian uppercasing) * Fix currency format test (U+00A0 instead of U+0020) * Enable Script_Extensions tests (test262) * Add support for Extended_Pictographic in regex Ref. https://github.com/tc39/ecma262/issues/1219. Bug: chromium:850334, v8:7825 Test: intl/*, test262/intl402/* Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I146080cdc1164db4a71f484918723cf302666df8 Reviewed-on: https://chromium-review.googlesource.com/1111857Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#54376}
-
- 14 Jun, 2018 2 commits
-
-
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: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53733}
-
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: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#53725}
-
- 13 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
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/1088911Reviewed-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}
-
- 05 Jun, 2018 2 commits
-
-
Mathias Bynens authored
It was shipped in Chrome 64. Bug: v8:4743 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I1084f55d19c0370d344acedeab630f03c02f49e5 Reviewed-on: https://chromium-review.googlesource.com/1086799Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#53514}
-
Mathias Bynens authored
It was shipped in Chrome 64. Bug: v8:5437 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I6d9ac762b2eafdf4e64fd1dd10dbce553a8455f9 Reviewed-on: https://chromium-review.googlesource.com/1086790Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#53510}
-
- 09 Apr, 2018 1 commit
-
-
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. Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533 Originally landed as r52416 / f9a2e24b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647 Reviewed-on: https://chromium-review.googlesource.com/1000540 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52492}
-
- 06 Apr, 2018 2 commits
-
-
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: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52420}
-
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: Hannes Payer <hpayer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52416}
-