searching for reviewer(rhunt)
16309c907652f1b1e46fa9bebf43faee5168b03d: Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 20 Jan 2020 12:23:12 +0000 - rev 573206
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt By cleaning up the register set APIs very slightly we can simplify the wrappers and make space for meaningful assertions. Differential Revision: https://phabricator.services.mozilla.com/D59673
8c7371a02fd7f7e6da78289ae3d5c22949490204: Bug 1609138 - Clean up float registers on arm64. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 20 Jan 2020 12:22:23 +0000 - rev 573205
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1609138 - Clean up float registers on arm64. r=rhunt Create a clearer distinction between the register's Encoding, which is its hardware name, and its Code, which is a dense encoding of bitwidth+Encoding along with a distinguished Invalid value. These concepts exist already but it gets out of hand when the FloatRegister uses a Code to encode the Encoding. Make FloatRegister contain separate fields for bitwidth, encoding, and validity, as it does on other platforms. Add assertions on validity of inputs and on the validity of the FloatRegister for some operations. And tidy up some, and rearrange the file to mirror the x86 file as much as possible. Expand the register name table so that it covers the possible range of Code and so that we won't reference the table OOB. Differential Revision: https://phabricator.services.mozilla.com/D59912
7d2c3216d225458e95547091e2d7e1efe067e88d: Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 20 Jan 2020 07:34:31 +0000 - rev 573193
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt By cleaning up the register set APIs very slightly we can simplify the wrappers and make space for meaningful assertions. Differential Revision: https://phabricator.services.mozilla.com/D59673
d2b7ff305b35b60bb8e27cb41db70f085728ca4f: Bug 1609138 - Clean up float registers on arm64. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 20 Jan 2020 07:33:52 +0000 - rev 573192
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1609138 - Clean up float registers on arm64. r=rhunt Create a clearer distinction between the register's Encoding, which is its hardware name, and its Code, which is a dense encoding of bitwidth+Encoding along with a distinguished Invalid value. These concepts exist already but it gets out of hand when the FloatRegister uses a Code to encode the Encoding. Make FloatRegister contain separate fields for bitwidth, encoding, and validity, as it does on other platforms. Add assertions on validity of inputs and on the validity of the FloatRegister for some operations. And tidy up some, and rearrange the file to mirror the x86 file as much as possible. Expand the register name table so that it covers the possible range of Code and so that we won't reference the table OOB. Differential Revision: https://phabricator.services.mozilla.com/D59912
d2457f7efd8a35a93816cbc6b47796c8cbc3b625: Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 14 Jan 2020 18:51:52 +0000 - rev 572743
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1608791 - Harden the Rabaldr register wrappers. r=rhunt By cleaning up the register set APIs very slightly we can simplify the wrappers and make space for meaningful assertions. Differential Revision: https://phabricator.services.mozilla.com/D59673
a7654938178351feeb8ec4e97994ffd9e4192214: Bug 1604740 - Zydis update. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 14 Jan 2020 19:00:47 +0000 - rev 572742
Push 12662 by ffxbld-merge at Mon, 10 Feb 2020 10:43:10 +0000
Bug 1604740 - Zydis update. r=rhunt This pulls the Zydis working branch to get a compile fix for Solaris that was upstreamed to Zydis by Oracle. I ran the zydis/update.sh script, then 'hg add'ed four new files, and ran a quick test - everything seems to work OK, wonders never cease. A diff of new vs old code shows the Solaris fix is included. The patch includes a change to update.sh that gets the pulled rev from the git repo, not from the command line Differential Revision: https://phabricator.services.mozilla.com/D59915
d33c1e0b18ab78924d4d74cf4fd72459faafb6d3: Bug 1568533 - make CaptureCommandList.h Append() template use aligned pointers r=rhunt
Petr Sumbera <petr.sumbera@oracle.com> - Fri, 13 Dec 2019 20:18:45 +0000 - rev 570664
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1568533 - make CaptureCommandList.h Append() template use aligned pointers r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D48952
f1547816cf326f1060f787fe9846e6bda7a33cbf: Bug 1602712 - First implementation of GetNewOrUsedBrowserAsync;r=rhunt
David Teller <dteller@mozilla.com> - Thu, 19 Dec 2019 10:57:13 +0000 - rev 569996
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1602712 - First implementation of GetNewOrUsedBrowserAsync;r=rhunt Depends on D56961 Differential Revision: https://phabricator.services.mozilla.com/D56962
050e0dee5088d44f1caff3bc82d3e02cd77f875b: Bug 1602712 - Split the parts of GetNewOrUsedBrowser that can be shared betwen sync and async;r=rhunt
David Teller <dteller@mozilla.com> - Thu, 19 Dec 2019 10:57:13 +0000 - rev 569995
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1602712 - Split the parts of GetNewOrUsedBrowser that can be shared betwen sync and async;r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D56961
4e7dd9fe1cde8e852a5653698614119941a08e0f: Bug 1604118 - Rename isRef, and tidy up. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 17 Dec 2019 13:39:41 +0000 - rev 569683
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1604118 - Rename isRef, and tidy up. r=rhunt Renames isRef() as isTypeIndex() and slightly change some error messages to distinguish indexed reference types from the more generic ones. Adds predicates on ValType to test various reference type subtypes, this reduces clutter. Slightly changes the code around existing uses of isRef() to improve error checking and provide resilience as we go forward toward other reference types, by calling out struct types specifically when they are the types we care about, and in one case changing from isRef() to !isAnyRef(), since that was the intent when we only had only the two cases AnyRef and Ref. Differential Revision: https://phabricator.services.mozilla.com/D57330
f23128d93320d080700b559277b8a034744adb8b: Bug 1603496 - abstract reference-type checking on JS values. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 16 Dec 2019 08:59:09 +0000 - rev 569232
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1603496 - abstract reference-type checking on JS values. r=rhunt Lift the code that checks JS values against reference types (and boxes anyref) from all the places where it is repeated into a common function. Clean up some code that assumes that the only reference types are anyref and funcref. Differential Revision: https://phabricator.services.mozilla.com/D56971
572a5cc1d0b5779c434dda5cba78a8ad59304eff: Bug 1603726 - Move tests to wasm/gc. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 16 Dec 2019 08:46:32 +0000 - rev 569231
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1603726 - Move tests to wasm/gc. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D57124
b0fb09545a0128c4ffdc4806e9f97cb3281f133c: Bug 1603772: Cranelift: replace native_pointer_{size,type} by const values; r=rhunt
Benjamin Bouvier <benj@benj.me> - Fri, 13 Dec 2019 19:35:58 +0000 - rev 569227
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1603772: Cranelift: replace native_pointer_{size,type} by const values; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D57127
fbeac1746d504ac63ad910d9c103ca2d65377d73: Bug 1603772: Revert the error type change when instantiating segments with Cranelift; r=rhunt
Benjamin Bouvier <benj@benj.me> - Fri, 13 Dec 2019 19:35:58 +0000 - rev 569226
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1603772: Revert the error type change when instantiating segments with Cranelift; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D57126
b92d5b9b880a082ca7c9a61ad9addc88c35f5ab8: Bug 1603772: Cranelift: only return the ret value when it's not used for internal purposes; r=rhunt
Benjamin Bouvier <benj@benj.me> - Fri, 13 Dec 2019 19:35:58 +0000 - rev 569225
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1603772: Cranelift: only return the ret value when it's not used for internal purposes; r=rhunt The return value of a wasm builtin call may just be used to check if the runtime caused an internal error (e.g. oom). There are assertions in code that the return value of wasm builtins not supposed to return a wasm value actually do this, so we shouldn't return values that are only internally used. This could have been done a simpler way by only having "FailureMode::NotZero" imply "do not return", but this is more future-proof like this: shared memory / atomics builtins both check the internal value *and* return it to the wasm value stack. Differential Revision: https://phabricator.services.mozilla.com/D57125
0b2556575c730985732cc1a975cd0da577c4a17d: Bug 1600124 - Don't crash debug builds if we get an empty rectangle passed. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Mon, 16 Dec 2019 00:20:55 +0000 - rev 569214
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1600124 - Don't crash debug builds if we get an empty rectangle passed. r=rhunt Depends on D57052 Differential Revision: https://phabricator.services.mozilla.com/D57053
e9dd453bc70df13a2fde4ec62d631d0eb26cad86: Bug 1601233: Output of mach vendor rust r=rhunt
Benjamin Bouvier <bbouvier@mozilla.com> - Thu, 05 Dec 2019 04:26:50 +0000 - rev 567751
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1601233: Output of mach vendor rust r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D55791
493c6741ff3e09d1f12c0a835540cfa6dd8d9cb2: Bug 1601233: Bump Cranelift to 497b4e1ca1d33dfd54314366d8e3a27a9fea225f; r=rhunt
Benjamin Bouvier <benj@benj.me> - Thu, 05 Dec 2019 04:26:50 +0000 - rev 567750
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1601233: Bump Cranelift to 497b4e1ca1d33dfd54314366d8e3a27a9fea225f; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D55790
827afbfc6f341761ec9cac4590c8b8fe8305f5b7: Bug 1597989: Tweak eager segments bound checks behavior for Cranelift; r=rhunt
Benjamin Bouvier <benj@benj.me> - Tue, 03 Dec 2019 15:31:39 +0000 - rev 567257
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1597989: Tweak eager segments bound checks behavior for Cranelift; r=rhunt The eagerBoundsCheck variable was desynchronized from compiler feature support for bulk memory operations, namely for Cranelift. This manually checks for Cranelift usage, and this will need to be reverted once bulk memory opcodes support land in Cranelift. Differential Revision: https://phabricator.services.mozilla.com/D55683
aa13508625cfa065111b7a37f0f7f83ac1480733: Bug 1597989: Output of mach rust vendor for the Cranelift bump; r=rhunt
Benjamin Bouvier <benj@benj.me> - Tue, 03 Dec 2019 15:28:28 +0000 - rev 567256
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1597989: Output of mach rust vendor for the Cranelift bump; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D53964
6c803ec19d693a984bfbb358aadd6ccb58622577: Bug 1597989: Bump cranelift to 152e317969702620; r=rhunt
Benjamin Bouvier <benj@benj.me> - Mon, 02 Dec 2019 16:27:30 +0000 - rev 567255
Push 12493 by ffxbld-merge at Mon, 06 Jan 2020 15:38:57 +0000
Bug 1597989: Bump cranelift to 152e317969702620; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D53963
493e233b678723773256ebf1148b01f07da8d5c3: Bug 1595395 - Use Shmem for gfx::PaintFragment so that we can handle serializing large images. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 28 Nov 2019 07:29:33 +0000 - rev 566022
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1595395 - Use Shmem for gfx::PaintFragment so that we can handle serializing large images. r=rhunt We serialize an empty sized fragment if memory allocation fails rather than failing serialization to avoid crashing. CrossProcessPaint::ReceiveFragment checks for an empty fragment, and reports an error to the caller, so this can be handled. Differential Revision: https://phabricator.services.mozilla.com/D55018
228dea1ec34951b2381c70fd90f81a300ece141d: Bug 1586411 - Don't crash if AttachLayerManager fails. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Sun, 24 Nov 2019 21:23:04 +0000 - rev 565446
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1586411 - Don't crash if AttachLayerManager fails. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D53760
8f8105dabc47d81976b1c73745053fbba8e2f2dc: Bug 1586411 - Don't crash if AttachLayerManager fails. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Sun, 24 Nov 2019 19:02:20 +0000 - rev 565442
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1586411 - Don't crash if AttachLayerManager fails. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D53760
dafab8054c071653c676b4cb7879e72fe40b8737: Bug 1469716 provide identifying handles in CreateWindowSurface() log messages r=rhunt
Karl Tomlinson <karlt+@karlt.net> - Wed, 20 Nov 2019 04:32:43 +0000 - rev 564615
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1469716 provide identifying handles in CreateWindowSurface() log messages r=rhunt These identifiers can be compared with messages from logging from nsWindow. Also clarify that this log is not intended to indicate each draw. Differential Revision: https://phabricator.services.mozilla.com/D53387
ef5aaf41caf7ba7a99c32b51b2a99d5fa577d14b: Bug 1581572 - Allow FuncRef on JS/wasm fast paths. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 13:16:54 +0000 - rev 564413
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow FuncRef on JS/wasm fast paths. r=rhunt Generalizes the work on AnyRef to also allow FuncRef values to flow out to JS through parameters on exits to JS or return values on entries from JS. (But not from JS to wasm, because that requires more elaborate type checking and is something we'll do later.) Differential Revision: https://phabricator.services.mozilla.com/D50436
ee84a26cfc8f96725128fdf679165f9848a73556: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 3. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 13:16:51 +0000 - rev 564412
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 3. r=rhunt,bbouvier Handle AnyRef argument passing and returns for the inlined JS->wasm fast path. Returns are easy: we unbox the AnyRef in the stub layer in the same way as for other entries. Calls are trickier: we must box on the JS side to fit into the current code structure, so there are some type-sniffing fast paths to avoid unnecessary allocation and if those fail then the generated code falls back to calling out to C++ to create a box for general value boxing. Differential Revision: https://phabricator.services.mozilla.com/D50031
636bc79ab0159103fd2bf2251c217f3a91bd4380: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 2. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 13:16:46 +0000 - rev 564411
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 2. r=rhunt,bbouvier An AnyRef is an opaque pointer type to wasm but can hold any JS Value; the Value is boxed when it enters wasm and unboxed when it enters JS. This boxing and unboxing must also happen when wasm and JS interact along the fast ("Jit") path, not just through the slow ("Interpreter") path. This patch allows an imported function (an exit) that returns anyref to have a fast path; the Value that we receive from the import is boxed into the wasm representation, which means allocating an object for it if the wasm representation can't accomodate it directly (currently only object or null). It also allows an exported function (an entry) that accept an anyref parameter to have a fast path; the value is similarly boxed in the stub layer. This patch does not handle argument passing for the inlined JS->wasm path; that is handled by a separate patch. Differential Revision: https://phabricator.services.mozilla.com/D49728
37323f3b5d16a4bf6093cae62ff7843a2d6e2890: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 1. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 13:16:42 +0000 - rev 564410
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 1. r=rhunt,bbouvier An AnyRef is an opaque pointer type to wasm but can hold any JS Value; the Value is boxed when it enters wasm and unboxed when it enters JS. This boxing and unboxing must also happen when wasm and JS interact along the fast ("Jit") path, not just through the slow ("Interpreter") path. This patch (part 1) handles the AnyRef -> Value cases: when Wasm calls JS with an AnyRef, or when Wasm returns to JS with an AnyRef, the AnyRef is unboxed into a Value. This patch does not handle the return value for the inlined JS->wasm path; that will be handled separately. Differential Revision: https://phabricator.services.mozilla.com/D49396
d8324c78fc1f90846faafeaa09321a061278cd93: Bug 1596026 - Do not use imported function if it's not an export. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 12:47:57 +0000 - rev 564409
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1596026 - Do not use imported function if it's not an export. r=rhunt The proper test for whether ref.func should return an original imported function for a given function index is a double test: first whether the index is in the import range, but then whether the original imported function is itself an exported function. This double test is visible several places in the code, notably in Instance::initElems and in GetFunctionExport. The second part of the test was however missing from Instance::funcRef. Differential Revision: https://phabricator.services.mozilla.com/D53004
17984c85d3bd062c67eaf40b2e8dacb4d096e10c: Bug 1596026 - FuncRef abstraction + document representation of funcref. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 12:48:00 +0000 - rev 564408
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1596026 - FuncRef abstraction + document representation of funcref. r=rhunt Cleanup patch: This documents the meaning of a 'funcref' value in wasm code (it is always a pointer to a JSFunction for which IsWasmExportedFunction is true) and implements a new abstraction, FuncRef, that can be used to handle functions with more precision than AnyRef. FuncRef and AnyRef are representationally compatible, so it is possible to have common code paths using only AnyRef for convenience, and to use FuncRef where we wish to be more explicit. Differential Revision: https://phabricator.services.mozilla.com/D53003
b50479e36a54536e902079df79efe42f12f63937: Bug 1581572 - Allow FuncRef on JS/wasm fast paths. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 08:57:04 +0000 - rev 564404
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow FuncRef on JS/wasm fast paths. r=rhunt Generalizes the work on AnyRef to also allow FuncRef values to flow out to JS through parameters on exits to JS or return values on entries from JS. (But not from JS to wasm, because that requires more elaborate type checking and is something we'll do later.) Differential Revision: https://phabricator.services.mozilla.com/D50436
4ba83138d78ec449cd742cc65fc1df5277c34db0: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 3. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 08:56:42 +0000 - rev 564403
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 3. r=rhunt,bbouvier Handle AnyRef argument passing and returns for the inlined JS->wasm fast path. Returns are easy: we unbox the AnyRef in the stub layer in the same way as for other entries. Calls are trickier: we must box on the JS side to fit into the current code structure, so there are some type-sniffing fast paths to avoid unnecessary allocation and if those fail then the generated code falls back to calling out to C++ to create a box for general value boxing. Differential Revision: https://phabricator.services.mozilla.com/D50031
b1796f474af442447cfdfd8676d93d540293cecb: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 2. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 08:56:19 +0000 - rev 564402
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 2. r=rhunt,bbouvier An AnyRef is an opaque pointer type to wasm but can hold any JS Value; the Value is boxed when it enters wasm and unboxed when it enters JS. This boxing and unboxing must also happen when wasm and JS interact along the fast ("Jit") path, not just through the slow ("Interpreter") path. This patch allows an imported function (an exit) that returns anyref to have a fast path; the Value that we receive from the import is boxed into the wasm representation, which means allocating an object for it if the wasm representation can't accomodate it directly (currently only object or null). It also allows an exported function (an entry) that accept an anyref parameter to have a fast path; the value is similarly boxed in the stub layer. This patch does not handle argument passing for the inlined JS->wasm path; that is handled by a separate patch. Differential Revision: https://phabricator.services.mozilla.com/D49728
f3018975e696c99281c37e42a8e43e4d28f5d062: Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 1. r=rhunt,bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 12:15:26 +0000 - rev 564401
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1581572 - Allow AnyRef on JS/wasm fast paths, part 1. r=rhunt,bbouvier An AnyRef is an opaque pointer type to wasm but can hold any JS Value; the Value is boxed when it enters wasm and unboxed when it enters JS. This boxing and unboxing must also happen when wasm and JS interact along the fast ("Jit") path, not just through the slow ("Interpreter") path. This patch (part 1) handles the AnyRef -> Value cases: when Wasm calls JS with an AnyRef, or when Wasm returns to JS with an AnyRef, the AnyRef is unboxed into a Value. This patch does not handle the return value for the inlined JS->wasm path; that will be handled separately. Differential Revision: https://phabricator.services.mozilla.com/D49396
3799c836c429d21299693f3bd92ccdc306863c31: Bug 1596026 - Do not use imported function if it's not an export. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 12:15:27 +0000 - rev 564400
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1596026 - Do not use imported function if it's not an export. r=rhunt The proper test for whether ref.func should return an original imported function for a given function index is a double test: first whether the index is in the import range, but then whether the original imported function is itself an exported function. This double test is visible several places in the code, notably in Instance::initElems and in GetFunctionExport. The second part of the test was however missing from Instance::funcRef. Differential Revision: https://phabricator.services.mozilla.com/D53004
90b91dd7995197df7e6c305b9abb17440072fd79: Bug 1596026 - FuncRef abstraction + document representation of funcref. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Nov 2019 08:55:26 +0000 - rev 564399
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1596026 - FuncRef abstraction + document representation of funcref. r=rhunt Cleanup patch: This documents the meaning of a 'funcref' value in wasm code (it is always a pointer to a JSFunction for which IsWasmExportedFunction is true) and implements a new abstraction, FuncRef, that can be used to handle functions with more precision than AnyRef. FuncRef and AnyRef are representationally compatible, so it is possible to have common code paths using only AnyRef for convenience, and to use FuncRef where we wish to be more explicit. Differential Revision: https://phabricator.services.mozilla.com/D53003
81babd897f9e153c23fa46dfb48e73855adb2418: Bug 1546592 - Allow element segments to be 'anyref', and generalize. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Thu, 17 Oct 2019 13:25:24 +0000 - rev 559331
Push 12177 by csabou@mozilla.com at Mon, 21 Oct 2019 14:52:16 +0000
Bug 1546592 - Allow element segments to be 'anyref', and generalize. r=rhunt The main changes here are: * Element segments that carry an elementexpr can carry a type T that is other than 'funcref', though we require T <: anyref * We generalize type handling around table initialization so that a table-of-T can be initialized from segment-of-U if U <: T. Also: * A declared element segment needs to have type funcref. The spec is silent on this, but it's a conservative choice. * A drive-by fix in serialize/deserialize, the 'kind' field was not being handled properly. This doesn't affect any shipping product as the serialize/deserialize code is currently unused. Differential Revision: https://phabricator.services.mozilla.com/D48690
8ea163ea6721438aa8a352b3d3f297fe2895373c: Bug 1586347 - Have BrowserChild internally take care of caching logic when checking if windows support protected media. r=dminor,rhunt
Bryce Seager van Dyk <bvandyk@mozilla.com> - Mon, 14 Oct 2019 19:10:39 +0000 - rev 558821
Push 12173 by aiakab@mozilla.com at Wed, 16 Oct 2019 15:08:16 +0000
Bug 1586347 - Have BrowserChild internally take care of caching logic when checking if windows support protected media. r=dminor,rhunt Currently when checking if a window supports protected media it's up to the caller interacting with a BrowserChild to check if a response is already cached, to perform the check if needed, and to then set the cached response if a call was made. This patch moves that logic internal to Browser child so that callers need to only worry about interacting with a single function. Differential Revision: https://phabricator.services.mozilla.com/D48585
69e2478e2a33f89f54bde0d38f1b790d52b9edad: Bug 1586252 - Adapt to spec change for src/dest idx for table.copy/memory.copy. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Wed, 09 Oct 2019 13:44:55 +0000 - rev 558419
Push 12169 by ffxbld-merge at Mon, 14 Oct 2019 16:59:29 +0000
Bug 1586252 - Adapt to spec change for src/dest idx for table.copy/memory.copy. r=rhunt Because implementations were not in agreement about this and the spec informally called for src-before-dest, the spec was changed to correspond to the dynamic and canonical operand order: dest-before-src. So we adapt to this. Differential Revision: https://phabricator.services.mozilla.com/D48176
7e6a7b2f9fc65dbdebca4465dec03d42af83d9e1: Bug 1546074 - Remove support for 'passive' syntax for segments. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Mon, 07 Oct 2019 09:21:57 +0000 - rev 557838
Push 12169 by ffxbld-merge at Mon, 14 Oct 2019 16:59:29 +0000
Bug 1546074 - Remove support for 'passive' syntax for segments. r=rhunt This removes support for 'passive' and makes our element and data segment syntax follow standard syntax much more closely. Element segments now require either 'func' or 'funcref' in the right position, and require a table index for active segments that don't use the designated MVP shorthand. Data segments require an offset when there's a memory index present. Also add support for the noise syntax (offset x) for the initialization offset in active segments. I did not add support for the variant of in-line elements in the table definition that allows the starting offset to be specified; this is followup work. Also tidy up some naming and comments in an attempt to clarify the flow in the encoder. Differential Revision: https://phabricator.services.mozilla.com/D48031
341a1c31fb152764937482abb2b0d81c63b3730c: Bug 1546074 - Remove support for 'passive' syntax for segments. r=rhunt
Lars T Hansen <lhansen@mozilla.com> - Fri, 04 Oct 2019 13:51:59 +0000 - rev 557669
Push 12169 by ffxbld-merge at Mon, 14 Oct 2019 16:59:29 +0000
Bug 1546074 - Remove support for 'passive' syntax for segments. r=rhunt This removes support for 'passive' and makes our element and data segment syntax follow standard syntax much more closely. Element segments now require either 'func' or 'funcref' in the right position, and require a table index for active segments that don't use the designated MVP shorthand. Data segments require an offset when there's a memory index present. Also add support for the noise syntax (offset x) for the initialization offset in active segments. I did not add support for the variant of in-line elements in the table definition that allows the starting offset to be specified; this is followup work. Also tidy up some naming and comments in an attempt to clarify the flow in the encoder. Differential Revision: https://phabricator.services.mozilla.com/D48031
08088ff7a8be5215b969199d2e8a7bb2d1dc77bd: Bug 1582042 - Use DocShell::SetIsActive from BrowserChild::MakeVisible for non top-level browsers. r=mconley,rhunt
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 27 Sep 2019 13:11:51 +0000 - rev 556695
Push 12169 by ffxbld-merge at Mon, 14 Oct 2019 16:59:29 +0000
Bug 1582042 - Use DocShell::SetIsActive from BrowserChild::MakeVisible for non top-level browsers. r=mconley,rhunt That is, for fission iframes. For top level stuff we rely on the tab switcher going through SetDocShellIsActive and such. See the expanded comment as for why. Ideally we could simplify this further by not making RecvRenderLayers update the visibility (which spins the refresh driver and such). It's a bit suspect because it's very easy to get to an inconsistent state if the browser chrome does something wrong. I'll try to do that, but for now this should improve the fission situation anyway. Differential Revision: https://phabricator.services.mozilla.com/D46706
c1fc5c5e39c044658f6ac614fd15d3fe99b1a5e5: Bug 1579157: Cranelift: mark Heap as read-only only in the huge memory case; r=rhunt
Benjamin Bouvier <benj@benj.me> - Mon, 09 Sep 2019 10:55:29 +0000 - rev 553538
Push 12169 by ffxbld-merge at Mon, 14 Oct 2019 16:59:29 +0000
Bug 1579157: Cranelift: mark Heap as read-only only in the huge memory case; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D45011
5b8583d3aa3782ca1140b20e493d1e10e6390ffc: Bug 1571341 - Default to using DocumentRelative for the root document being drawn, since callers generally expect coordinates relative to the document. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 14 Aug 2019 10:23:39 +0000 - rev 548382
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1571341 - Default to using DocumentRelative for the root document being drawn, since callers generally expect coordinates relative to the document. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D41728
b8c5fc82d21ddb485d6565dd49f31f98e95a684f: Bug 1569930 - Handle races in CrossProcessPaint without crashing, and instead report it back to the caller. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 14 Aug 2019 10:23:34 +0000 - rev 548381
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1569930 - Handle races in CrossProcessPaint without crashing, and instead report it back to the caller. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D41727
690edc0673c61f056f8a4106237f79b1f6a734ba: Bug 1570369 - Part 2: Use IPDL refcounted for PAPZInputBridge, r=rhunt
Nika Layzell <nika@thelayzells.com> - Thu, 08 Aug 2019 16:46:22 +0000 - rev 547613
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1570369 - Part 2: Use IPDL refcounted for PAPZInputBridge, r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D40253
f2901a5df92f7ae9b30bd364f6983f035870e515: Bug 1569974 - Don't try to deference an empty Maybe when starting CrossProcessPaint with a rect. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 31 Jul 2019 19:01:05 +0000 - rev 546174
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1569974 - Don't try to deference an empty Maybe when starting CrossProcessPaint with a rect. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D39964
7a1b62721c249d890333a4a6dfa876e08a070771: Bug 1570339: Skip wasm atomic fence if atomics aren't enabled/supported; r=rhunt
Benjamin Bouvier <benj@benj.me> - Wed, 31 Jul 2019 16:05:47 +0000 - rev 546104
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1570339: Skip wasm atomic fence if atomics aren't enabled/supported; r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D40054
634c5f669f3a6cb6b7e3f851af20927ebcfc2d88: Bug 1562722 - Don't apply the background color to anything except the root document when using CrossProcessPaint. r=rhunt
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 11 Jul 2019 14:01:15 +0000 - rev 542994
Push 11848 by ffxbld-merge at Mon, 26 Aug 2019 19:26:25 +0000
Bug 1562722 - Don't apply the background color to anything except the root document when using CrossProcessPaint. r=rhunt Differential Revision: https://phabricator.services.mozilla.com/D37679