7bd84a644d2b3a40ad2043870a2b74663b327b2c: Bug 1506323 - Add JS::PrintError to public API. r=evilpie
Philip Chimento <philip.chimento@gmail.com> - Wed, 13 May 2020 16:10:25 +0000 - rev 593409
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1506323 - Add JS::PrintError to public API. r=evilpie Differential Revision: https://phabricator.services.mozilla.com/D73519
e365cbeabc4f8d2182bfc92cbf206bbeef98fee7: Bug 1634135: Turn new regexp engine on by default in Nightly r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:24:04 +0000 - rev 593408
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Turn new regexp engine on by default in Nightly r=mgaudet Pull the lever! (After responsibly waiting for 78 to open.) Differential Revision: https://phabricator.services.mozilla.com/D73120
3d92a3a541ffab165ca1590ed57ea99ec7dd2f0e: Bug 1634135: Update expectations for wpt IndexedDB structured clone tests r=dom-workers-and-storage-reviewers,asuth
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:23:46 +0000 - rev 593407
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Update expectations for wpt IndexedDB structured clone tests r=dom-workers-and-storage-reviewers,asuth The regexp engine is adding support for the dotAll flag (/s). As a result, `/abc/gimsuy` in structured-clone.any.js (https://searchfox.org/mozilla-central/source/testing/web-platform/tests/IndexedDB/structured-clone.any.js#159) is no longer a syntax error, which means that the structured cloning tests don't all immediately fail. Some of them still fail, presumably for different reasons. This patch is the result of running the wpt tests and updating the expected results according to the instructions here: https://searchfox.org/mozilla-central/source/testing/web-platform/README.md#158-173 Try build: https://searchfox.org/mozilla-central/source/testing/web-platform/README.md#158-173 Differential Revision: https://phabricator.services.mozilla.com/D74341
5871f4ecce8716009e676c18ce496e5f3bbd8651: Bug 1634135: Update test_xrayToJS to handle Regexp.prototype.dotAll r=bholley
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:23:33 +0000 - rev 593406
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Update test_xrayToJS to handle Regexp.prototype.dotAll r=bholley We are adding support for the dotAll (/s) RegExp flag, so the list of expected properties on the RegExp prototype has to be updated. Differential Revision: https://phabricator.services.mozilla.com/D74149
5c0565636d06c53ae0d4455158164da0f3d9cb6a: Bug 1634135: Don't leak Isolate r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:23:20 +0000 - rev 593405
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Don't leak Isolate r=mgaudet ASAN found a leak. We destroy the isolate with a level of indirection through RegexpAPI so that JSContext doesn't have to be able to see the full definition of Isolate. Differential Revision: https://phabricator.services.mozilla.com/D74151
16a1d1bbdd3e41e3368560d5847fced5857970fc: Bug 1634135: Update tests to expect RegExp.prototype.dotAll r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:22:55 +0000 - rev 593404
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Update tests to expect RegExp.prototype.dotAll r=mgaudet These two tests need to be updated to be aware of the new dotAll flag. If we ever have to turn off the new engine, this patch should also be temporarily reverted. Differential Revision: https://phabricator.services.mozilla.com/D73119
98d7859686e6901f49799b0590b271d0821349a4: Bug 1634135: Throw 'regexp too big' errors properly r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:22:52 +0000 - rev 593403
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Throw 'regexp too big' errors properly r=mgaudet If a regular expression is too big, the assembler may fail with RegExpError::kTooLarge. When it does so, we want to throw an error: "regexp too big". Until the most recent reimport of irregexp, we were actually reporting an OOM in these cases, because `CompilationResult::code` was default-constructed as an UndefinedValue and we took the "OOM in GetCode" path. Now `CompilationResult::code` is a Handle, so we crash if we try to access the value. Making the situation slightly more complicated is the fact that we still have a macroassembler live, which means that we can't GC, which means that we can't report an error. The old code used an AutoSuppressGC for this (https://searchfox.org/mozilla-central/source/js/src/irregexp/RegExpEngine.cpp#1703), but that seems like an extremely blunt instrument. Instead, I've refactored `CompilePattern` to call a separate `Assemble` function. This means that we clean up the macroassembler before we call `JS_ReportErrorASCII`. The new function is a straight copy-paste of the old code, except for error handling and `.` to `->` conversions for the values being passed by reference. Note that the order of checks has changed after calling `compiler->Assemble(...)`: now we check `result.Succeeded()` before examining `result.code`. We also change the shared labels in SMRegExpMacroAssembler to be NonAssertingLabels. This suppresses assertions in the Label destructor that they are not used without being bound. The assertion is already suppressed for OOM (https://searchfox.org/mozilla-central/source/js/src/jit/Label.h#82-86), which is why we did not trigger it previously. Differential Revision: https://phabricator.services.mozilla.com/D73758
534658e9995271198d6a71278787d8aa6e02e09f: Bug 1634135: Update shim code r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:22:46 +0000 - rev 593402
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Update shim code r=mgaudet There are a few changes here: 1. The code that used to be in wrapBody was moved to RegExpCompiler::PreprocessRegExp. 2. The `code` field in RegExpCompileData used to be a bare Object, and is now a Handle<Object>. (This makes named captures way easier to implement, because it lets us to allocate GC things while parsing a regexp without angering the hazard analysis.) I also took this opportunity to remove some dead code in the shim implementation of Handle. 3. Upstream V8 made a change to simplify the interface with the interpreter. Previously, the caller of IrregexpInterpreter::MatchForCallFromRuntime was responsible for allocating enough memory to hold both the capture results and the scratch registers. Now, the interpreter has the same interface as the compiler: the caller passes in a buffer large enough to hold the capture results, and the memory for the scratch registers is allocated internally. This requires a few small additions to the shim (IsInRange plus new methods on JSRegExp and SmallVector). Differential Revision: https://phabricator.services.mozilla.com/D73118
09b8bab47f6b8bbb6fe9ca66560999874eefa981: Bug 1634135: Fresh import of irregexp r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:22:44 +0000 - rev 593401
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Fresh import of irregexp r=mgaudet This is as good a time as any to pull in some recent upstream changes (many of which I wrote). This patch was auto-generated using import-irregexp.py. The necessary changes to the shim code are in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D73117
596dca6e3ed1c15c930271f09eb03f513d329b5b: Bug 1634135: Eagerly tier up for long regexp inputs r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:20:25 +0000 - rev 593400
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Eagerly tier up for long regexp inputs r=mgaudet Interpreted bytecode is ~3-5 times slower than compiled code, but ~5-10 times smaller. In general it seems like this is a good trade-off for the first few iterations, but for particularly long input strings this can cause a significant slowdown before we tier up. V8 eagerly tiers up to compiled code when the input string is 1000+ characters long. Following their lead on this fixes a significant regression in sunspider-regexp-dna. Differential Revision: https://phabricator.services.mozilla.com/D73116
c474eb63f626923dc192a65f4f144a280f544fe2: Bug 1634135: Disable named capture parsing until fully supported r=mgaudet
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:19:57 +0000 - rev 593399
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Disable named capture parsing until fully supported r=mgaudet The engine supports parsing named captures, but we don't have the code in place to expose the captured groups. Until we do, this code will make sure that we get a syntax error when parsing them. Differential Revision: https://phabricator.services.mozilla.com/D73115
e0f929077cce95cfa1f2928cb8d4d631cb3e589a: Bug 1634135: Fix look-behind back-references r=jandem
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:19:24 +0000 - rev 593398
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Fix look-behind back-references r=jandem If a look-behind back-reference succeeds, we have to subtract the length of the capture from the current position (so that the current position points to the beginning of the capture). We don't have the length in a register, so we have to read it from the capture registers, which are stored on the stack. However, we pushed the initial value of the current position, so the stack pointer is offset by one word from where we expect. The fix is to pop the saved value *before* subtracting the length. With this fix, we pass all the test262 tests for look-behind assertions, dotAll, and unicode property escapes. (I will turn them on in a separate bug.) Differential Revision: https://phabricator.services.mozilla.com/D73113
80d21da86415c1c8fa7f1798f0010716ff963e2d: Bug 1634135: Fix dummy TokenStream r=djvj
Iain Ireland <iireland@mozilla.com> - Wed, 13 May 2020 16:19:11 +0000 - rev 593397
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634135: Fix dummy TokenStream r=djvj This was broken by changes to token streams in bug 1592105. Differential Revision: https://phabricator.services.mozilla.com/D73112
b9a968157038332e31a8c059222057b53bb39109: Bug 1605895 - Advance the diagnostic assertion when an http channel on the child process loading CSS does not notify OnStopRequest, r=michal,necko-reviewers
Honza Bambas <honzab.moz@firemni.cz> - Wed, 13 May 2020 16:18:32 +0000 - rev 593396
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1605895 - Advance the diagnostic assertion when an http channel on the child process loading CSS does not notify OnStopRequest, r=michal,necko-reviewers Differential Revision: https://phabricator.services.mozilla.com/D72007
0230d23f652f508c53c016c1ca0e127c8da6b831: Bug 1634650 - Add whitelisting of domain suffixes for URIFixup. r=harry
Marco Bonardo <mbonardo@mozilla.com> - Wed, 13 May 2020 16:05:04 +0000 - rev 593395
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1634650 - Add whitelisting of domain suffixes for URIFixup. r=harry Differential Revision: https://phabricator.services.mozilla.com/D74015
cd6d298b0d8948d5bf62bbf340531b718b5eaf92: Bug 1629796: Replace finalization iterator with multiple callback calls. r=jonco
André Bargull <andre.bargull@gmail.com> - Wed, 13 May 2020 15:25:24 +0000 - rev 593394
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1629796: Replace finalization iterator with multiple callback calls. r=jonco Implements the spec changes from: https://github.com/tc39/proposal-weakrefs/pull/187 The spec change removes the `FinalizationRegistryCleanupIterator` in favour of calling the clean-up callback for each finalised value. It also allows to call `cleanupSome()` within the callback function. `FinalizationRegistryObject::cleanupQueuedRecords()` has been changed to iterate from back to front, because this allows us to call `GCVector::popCopy()`, which makes it more efficient to remove entries from the `records` vector. Differential Revision: https://phabricator.services.mozilla.com/D70821
cd9a71d12e7d85edb168833a8a856f658d11cf72: Bug 1596481 - Try to update extensions installed via policy. r=mixedpuppy
Michael Kaply <mozilla@kaply.com> - Wed, 13 May 2020 16:00:13 +0000 - rev 593393
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1596481 - Try to update extensions installed via policy. r=mixedpuppy Differential Revision: https://phabricator.services.mozilla.com/D74340
39a3f904ac838595ac432532e0792e7c353a967f: Bug 1637418 - Allow whole module environment to declare valid ref.func targets. r=lth
Ryan Hunt <rhunt@eqrion.net> - Wed, 13 May 2020 15:49:06 +0000 - rev 593392
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1637418 - Allow whole module environment to declare valid ref.func targets. r=lth The CG agreed to resolve reference-types#76 by treating all ocurrences of ref.func in the 'module environment' as declaring a valid ref.func target for the code section. This means we need to allow references to be forward declared via globals, exports, and the start section. [1] https://github.com/WebAssembly/reference-types/issues/76 Differential Revision: https://phabricator.services.mozilla.com/D74969
8ab8caf5e56be92a1dc0dc774c1e5f770aed739f: Bug 1637469 - Rename browser_aboutdebugging_navigate_to_url.js test r=jdescottes
David Walsh <dwalsh@mozilla.com> - Wed, 13 May 2020 15:08:31 +0000 - rev 593391
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1637469 - Rename browser_aboutdebugging_navigate_to_url.js test r=jdescottes Differential Revision: https://phabricator.services.mozilla.com/D75114
d3d7530ced83d7c4a551384a3305e6f32a90c1d1: Bug 1636316 - Disable defective optimization in DeserializeIndexValueHelper::DispatchAndWait. r=asuth,dom-workers-and-storage-reviewers
Simon Giesecke <sgiesecke@mozilla.com> - Wed, 13 May 2020 15:49:46 +0000 - rev 593390
Push 13186 by ffxbld-merge at Mon, 01 Jun 2020 09:52:46 +0000
Bug 1636316 - Disable defective optimization in DeserializeIndexValueHelper::DispatchAndWait. r=asuth,dom-workers-and-storage-reviewers Differential Revision: https://phabricator.services.mozilla.com/D75046
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip