- 09 Mar, 2020 1 commit
-
-
Dan Elphick authored
String::NewFromLiteral is a templated function that takes a char[N] argument that can be used as an alternative to String::NewFromUtf8 and returns a Local<String> rather than a MaybeLocal<String> reducing the number of ToLocalChecked() or other checks. Since the string length is known at compile time, it can statically assert that the length is less than String::kMaxLength, which means that it can never fail at runtime. This also converts all found uses of NewFromUtf8 taking a string literal or a variable initialized from a string literal to use the new API. In some cases the types of stored string literals are changed from const char* to const char[] to ensure the size is retained. This API does introduce a small difference compared to NewFromUtf8. For a case like "abc\0def", NewFromUtf8 (using length -1 to infer length) would treat this as a 3 character string, whereas the new API will treat it as a 7 character string. As a drive-by fix, this also fixes all redundant uses of v8::NewStringType::kNormal when passed to any of the String::New* functions. Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66622}
-
- 22 Aug, 2019 1 commit
-
-
Joshua Litt authored
Bug: chromium:996232 Change-Id: I1df23835c18f5491a95e2faff17594ee7419cf75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763157 Auto-Submit: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63327}
-
- 21 Aug, 2019 1 commit
-
-
Joshua Litt authored
When regexp match indices are enabled, we stash required data in the JSRegExpResult object, and then build a JSRegExpResultIndices object lazily when the 'indices' property is accessed. This cl simply checks that fast and slow paths produce the same values for result.indices and result.indices.groups. Change-Id: I6322d8eaef4c6e5a0ed3a5aef8b2ff05ac2b2c7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763249Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63301}
-
- 26 Jun, 2019 2 commits
-
-
Jakob Kummerow authored
Just the low-hanging fruit. There is more to do. Bug: v8:2487 Change-Id: Ia9afa32797960f6c4c7c4fa0f39c70efc63663e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669698Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#62397}
-
Jakob Gruber authored
There's no reason to use the API RegExp type instead of the internal JSRegExp type. In fact, the parsed flags end up in Runtime_CreateRegExpLiteral, which assumes them to be of type JSRegExp::Flags. Drive-by: Additional asserts and helper functions in JSRegExp. Bug: v8:9359 Change-Id: I5c12aba7d4e39a4891fb23d8b47c55fc480a28d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667004Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62376}
-
- 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}
-
- 23 May, 2019 1 commit
-
-
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}
-
- 10 May, 2019 1 commit
-
-
Andrew Grieve authored
FATAL() calls with more than one argument are preserved. The rest of chrome does this as well. Stack traces and minidumps should be sufficient for analyzing the reason for crashes. This saves 110kb for Android arm32. Bug: chromium:958807 Change-Id: I88a1ec82f1ed7bd5e7dbccf6d645d5584f16de82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598159 Commit-Queue: Andrew Grieve <agrieve@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61426}
-
- 08 Mar, 2019 1 commit
-
-
Jakob Gruber authored
My standard procedure for debugging regexp builtin fuzzer finds is to turn on verbose mode and run the repro. This extends verbose output to include the generated script which contains e.g. the regexp pattern, the subject string, and the actual function call. Tbr: yangguo@chromium.org Bug: v8:8968 Change-Id: I0c7e930f4cbd34014f2781ca280919c5b002b049 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511276Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60120}
-
- 16 Oct, 2018 1 commit
-
-
Jakob Gruber authored
If `out` is empty accessing `out.back()` is invalid. TBR=yangguo@chromium.org Bug: chromium:894934 Change-Id: I7286c5b6a9857f1cdb2bcaf383094bee65bac393 Reviewed-on: https://chromium-review.googlesource.com/c/1282565Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56669}
-
- 23 Jul, 2018 1 commit
-
-
Ross Mcilroy authored
Replace with isolate version. BUG=v8:7754 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iac7091b983960d22b892074c5fd0a97dee9025c9 Reviewed-on: https://chromium-review.googlesource.com/1146332 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#54604}
-
- 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}
-
- 09 Feb, 2018 1 commit
-
-
jgruber authored
Since we naively build the JS source code through concatenation, we need to ensure the regexp literal does not end up being interpreted as a multiline comment: const re = /*/; Bug: v8:6741,chromium:808418 Change-Id: Id52fbd2d62c14fc634d05fa1b0192ab86cc9e4fc Reviewed-on: https://chromium-review.googlesource.com/905667Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51206}
-
- 31 Jan, 2018 2 commits
-
-
jgruber authored
The hash avoids assigning all CHECK failures to the same clusterfuzz report. Bug: chromium:805970 Change-Id: Ia52da335ea86fbc7cc924dd81a893722a6d3d92e Reviewed-on: https://chromium-review.googlesource.com/894323Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#50992}
-
jgruber authored
The fuzzer found a couple of cases that exploited comments of the form: function test() { const re = /*.../; const str = '...*/...'; let result; try { result = re.exec(str); } catch (e) { /* ... */ } } Note that the first line does not contain a regexp literal, it starts a comment instead. The second line terminates the comment. This fixes detection of such cases by initializing `result` to null. TBR=yangguo@chromium.org Bug: chromium:805970 Change-Id: I5d46db9892e2b4e71cdc2907cebf07a2e33b7a0e Reviewed-on: https://chromium-review.googlesource.com/894403Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#50991}
-
- 18 Jan, 2018 1 commit
-
-
jgruber authored
This fuzzer randomly generates calls to regexp builtins, runs each on the slow and fast path, and verifies that their result is the same. Change-Id: Ia91b0c8afcdaf64835a9bb7b9a470610fbb75fc8 Reviewed-on: https://chromium-review.googlesource.com/833922 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#50670}
-