searching for reviewer(luke)
09493e80dbe7: Bug 1512410 part 2 - Don't create a TypeNewScript for cross-realm constructors, add more asserts. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Sat, 08 Dec 2018 18:10:29 +0000 - rev 449663
Push 110408 by rgurzau@mozilla.com at Sat, 08 Dec 2018 21:37:52 +0000
Bug 1512410 part 2 - Don't create a TypeNewScript for cross-realm constructors, add more asserts. r=luke Depends on D13903 Differential Revision: https://phabricator.services.mozilla.com/D13904
c24a1c1237ba: Bug 1512410 part 1 - Add a realm check to the NewObjectCache to fix a bug with same-compartment realms. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Sat, 08 Dec 2018 18:06:17 +0000 - rev 449662
Push 110408 by rgurzau@mozilla.com at Sat, 08 Dec 2018 21:37:52 +0000
Bug 1512410 part 1 - Add a realm check to the NewObjectCache to fix a bug with same-compartment realms. r=luke Differential Revision: https://phabricator.services.mozilla.com/D13903
4201f7161e7a: Bug 1509283: Compile the last wasm function batch on the main thread; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 22 Nov 2018 11:12:20 +0100 - rev 448498
Push 110194 by bbouvier@mozilla.com at Wed, 28 Nov 2018 16:25:03 +0000
Bug 1509283: Compile the last wasm function batch on the main thread; r=luke
5219f57277c4: Bug 1505774 - Introduce nullref type. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 06 Nov 2018 14:50:59 +0100 - rev 447941
Push 110097 by lhansen@mozilla.com at Mon, 26 Nov 2018 07:30:51 +0000
Bug 1505774 - Introduce nullref type. r=luke Mostly this is straightforward: add NullRef in the various type enums and make sure we handle it everywhere (sometimes it's valid; other times it's a fatal error because it should not appear in that context). Some type calculus code had to move out of WasmOpIter and into ModuleEnvironment in order to be available from the decoder generally. Also, since NullRef is not an expressed type but only the type of null constants in the type checker until we know better, we have to be careful to avoid using it as the value type of null values. The text syntax for a null constant in the s-expression form is "(ref.null)", with the parens required. In the stacky syntax the parens are not required. The encoding of ref.null is now incompatible with our old encoding, so there's a required update to the gc-feature opt in version (to version 2), code tagged with version 1 will no longer run but there's a sensible error message printed for that.
f03c9e85b401: Bug 1505774 - Update test cases for NullRef. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 16 Nov 2018 13:45:22 +0100 - rev 447940
Push 110097 by lhansen@mozilla.com at Mon, 26 Nov 2018 07:30:51 +0000
Bug 1505774 - Update test cases for NullRef. r=luke Two major changes: - ref.null no longer carries a type - because the encoding is backwards-incompatible, all test cases must gc_feature_opt_in with version 2 instead of 1
3a55e6ff3190: Bug 1508416: Check TLS initialization before reading sAlreadyHandlingTrap. r=luke
David Major <dmajor@mozilla.com> - Mon, 19 Nov 2018 20:30:51 -0500 - rev 447122
Push 109985 by dmajor@mozilla.com at Tue, 20 Nov 2018 01:59:06 +0000
Bug 1508416: Check TLS initialization before reading sAlreadyHandlingTrap. r=luke
5a42e724df88: Bug 1507564: Bind code labels when generating lazy table stubs; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 15 Nov 2018 21:25:52 +0000 - rev 446752
Push 109924 by rgurzau@mozilla.com at Fri, 16 Nov 2018 17:56:06 +0000
Bug 1507564: Bind code labels when generating lazy table stubs; r=luke A lazy stub could generate CodeLabels on x86, because of a constant NaN generated for the entry's epilogue that ended up in a constant pool. We need to actually bind these code labels in general. Differential Revision: https://phabricator.services.mozilla.com/D12052
ea1da7c247ea: Bug 1500167 - Support multiple tables in wasm. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 23 Oct 2018 15:52:38 +0200 - rev 446166
Push 109843 by lhansen@mozilla.com at Wed, 14 Nov 2018 12:36:35 +0000
Bug 1500167 - Support multiple tables in wasm. r=luke This is largely plumbing, and lots of it. The main complication is that function tables historically have had two representations: one optimized representation for tables that don't escape out of the instance, and one fatter representation for tables that do (and that must contain instance pointers). With multiple tables, we may table.copy from a function table with one representation to one with the other representation, in the limit this means changing the representation of the skinny table to be fat. However, at the time when we discover this, code may already have been generated that knows about the skinny representation, so we can't actually perform such a representation change. A somewhat reasonable solution to this is to just make all function tables fat - we're going to be changing things soonish anyway, when we make anyfunc / funcref a first-class type.
5c97eca29dd7: Bug 1450263 - Basic generalized table type, part 2: table.get/set/grow/size. r=luke
Lars T Hansen <lhansen@mozilla.com> - Thu, 18 Oct 2018 10:23:20 +0200 - rev 446165
Push 109843 by lhansen@mozilla.com at Wed, 14 Nov 2018 12:36:35 +0000
Bug 1450263 - Basic generalized table type, part 2: table.get/set/grow/size. r=luke Implement table.get, table.set, table.grow, and table.size, and also recognize GcFeatureOptIn version 2. The table operations except table.size and table.copy will fail validation on tables of anyfunc since we don't have any anyfunc values (and we won't accept null as an anyfunc value at the moment). Similarly, table.init will fail on tables of anyref since element segments can only reference functions and we don't yet accept anyfunc as a subtype of anyref.
01a7e880049a: Bug 1450263 - Basic generalized table type, part 1: table-of-anyref. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 15 Oct 2018 11:48:42 +0200 - rev 446164
Push 109843 by lhansen@mozilla.com at Wed, 14 Nov 2018 12:36:35 +0000
Bug 1450263 - Basic generalized table type, part 1: table-of-anyref. r=luke We extend the concept of wasm tables: - table-of-anyref - "anyref" as type name for table elements in JS API The evolving spec for this feature is here: https://github.com/lars-t-hansen/moz-gc-experiments/blob/master/version2.md and is generally intended to track the evolving reftypes proposal. The generalized tables are under an ifdef that depend on the GC types ifdef. This is too restrictive; we will need to split the GC types ifdef into one for reftypes (to be enabled soon) and one for the rest of the GC feature (to be enabled later), and generalized tables only depend on the former. But that doesn't have to happen as part of this patch.
959d83958227: Bug 1495879: Fix register macros and re-enable wasm on aarch64-windows. r=luke
David Major <dmajor@mozilla.com> - Fri, 09 Nov 2018 12:43:41 -0500 - rev 445389
Push 109741 by dmajor@mozilla.com at Fri, 09 Nov 2018 17:41:12 +0000
Bug 1495879: Fix register macros and re-enable wasm on aarch64-windows. r=luke
520d47760632: Bug 1489698 - Add moz.build for js/src/wasm. r=luke,froydnj
Ted Campbell <tcampbell@mozilla.com> - Fri, 07 Sep 2018 21:51:33 -0400 - rev 443935
Push 109483 by tcampbell@mozilla.com at Thu, 01 Nov 2018 17:35:45 +0000
Bug 1489698 - Add moz.build for js/src/wasm. r=luke,froydnj
ca965ec1bc91: Bug 1501703: Move the custom section read before finishing a wasm module's metadata; r=luke
Benjamin Bouvier <benj@benj.me> - Wed, 24 Oct 2018 17:28:27 +0200 - rev 442921
Push 109259 by bbouvier@mozilla.com at Thu, 25 Oct 2018 07:08:21 +0000
Bug 1501703: Move the custom section read before finishing a wasm module's metadata; r=luke
3c04e96db3e6: Bug 1496892 - Check script compartment instead of realm in TypeScript::SetArgument. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Fri, 19 Oct 2018 15:38:19 +0000 - rev 442347
Push 109155 by archaeopteryx@coole-files.de at Mon, 22 Oct 2018 17:39:15 +0000
Bug 1496892 - Check script compartment instead of realm in TypeScript::SetArgument. r=luke We can call this for a cross-realm script when defining a property on an arguments object. Differential Revision: https://phabricator.services.mozilla.com/D9226
d46116aa3527: Bug 1500121 - Give IdValueVector some inline capacity. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 18 Oct 2018 18:34:13 +0000 - rev 442152
Push 109116 by dvarga@mozilla.com at Sat, 20 Oct 2018 10:33:59 +0000
Bug 1500121 - Give IdValueVector some inline capacity. r=luke Differential Revision: https://phabricator.services.mozilla.com/D9117
42319047f3d9: Bug 1487100 - Allow opening the input stream for original content when alt-data is available r=michal,luke
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 17 Oct 2018 12:27:37 +0000 - rev 441874
Push 109058 by ebalazs@mozilla.com at Thu, 18 Oct 2018 10:27:42 +0000
Bug 1487100 - Allow opening the input stream for original content when alt-data is available r=michal,luke In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server. To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry. Depends on D8071 Differential Revision: https://phabricator.services.mozilla.com/D8072
e37adb23fd48: Bug 1487100 - Allow calling nsICacheInfoChannel.preferAlternativeDataType(altDataType, contentType) multiple times r=michal,luke
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 17 Oct 2018 13:58:30 +0000 - rev 441873
Push 109058 by ebalazs@mozilla.com at Thu, 18 Oct 2018 10:27:42 +0000
Bug 1487100 - Allow calling nsICacheInfoChannel.preferAlternativeDataType(altDataType, contentType) multiple times r=michal,luke This patch changes the way we set and handle the preferred alternate data type. It is no longer just one choice, but a set of preferences, each conditional on the contentType of the resource. For example: var cc = chan.QueryInterface(Ci.nsICacheInfoChannel); cc.preferAlternativeDataType("js-bytecode", "text/javascript"); cc.preferAlternativeDataType("ammended-text", "text/plain"); cc.preferAlternativeDataType("something-else", ""); When loaded from the cache, the available alt-data type will be checked against "js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes. Note that the alt-data type could be "something-else" even if the contentType is "text/javascript". The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>. Differential Revision: https://phabricator.services.mozilla.com/D8071
7f9d03c29a6f: Bug 1487100 - Allow opening the input stream for original content when alt-data is available r=michal,luke
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 17 Oct 2018 12:27:37 +0000 - rev 441836
Push 109058 by ebalazs@mozilla.com at Thu, 18 Oct 2018 10:27:42 +0000
Bug 1487100 - Allow opening the input stream for original content when alt-data is available r=michal,luke In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server. To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry. Depends on D8071 Differential Revision: https://phabricator.services.mozilla.com/D8072
dd1c31ea78c2: Bug 1487100 - Allow calling nsICacheInfoChannel.preferAlternativeDataType(altDataType, contentType) multiple times r=michal,luke
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 17 Oct 2018 13:58:30 +0000 - rev 441835
Push 109058 by ebalazs@mozilla.com at Thu, 18 Oct 2018 10:27:42 +0000
Bug 1487100 - Allow calling nsICacheInfoChannel.preferAlternativeDataType(altDataType, contentType) multiple times r=michal,luke This patch changes the way we set and handle the preferred alternate data type. It is no longer just one choice, but a set of preferences, each conditional on the contentType of the resource. For example: var cc = chan.QueryInterface(Ci.nsICacheInfoChannel); cc.preferAlternativeDataType("js-bytecode", "text/javascript"); cc.preferAlternativeDataType("ammended-text", "text/plain"); cc.preferAlternativeDataType("something-else", ""); When loaded from the cache, the available alt-data type will be checked against "js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes. Note that the alt-data type could be "something-else" even if the contentType is "text/javascript". The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>. Differential Revision: https://phabricator.services.mozilla.com/D8071
01368a04b48a: Bug 1499198 - Use a constant memory load instead of a word reference in convertUint64ToDouble. r=luke
Benjamin Bouvier <benj@benj.me> - Wed, 17 Oct 2018 18:10:24 +0200 - rev 441678
Push 109028 by ryanvm@gmail.com at Wed, 17 Oct 2018 16:53:18 +0000
Bug 1499198 - Use a constant memory load instead of a word reference in convertUint64ToDouble. r=luke
463344943de8: Bug 1495878: Disable wasm signal handlers in the aarch64 Windows build. r=luke
David Major <dmajor@mozilla.com> - Wed, 03 Oct 2018 17:06:23 -0400 - rev 439423
Push 108587 by dmajor@mozilla.com at Wed, 03 Oct 2018 21:34:26 +0000
Bug 1495878: Disable wasm signal handlers in the aarch64 Windows build. r=luke
9d0ccdab956d: Bug 1495573 - avoid double refcount decrement along failure path. r=luke
Lars T Hansen <lhansen@mozilla.com> - Tue, 02 Oct 2018 14:12:41 +0200 - rev 439355
Push 108559 by lhansen@mozilla.com at Wed, 03 Oct 2018 10:36:19 +0000
Bug 1495573 - avoid double refcount decrement along failure path. r=luke
2aec59694789: Bug 1490251: Add a pref switch to use Cranelift for wasm compilation; r=luke
Benjamin Bouvier <benj@benj.me> - Thu, 13 Sep 2018 12:32:17 +0200 - rev 438654
Push 108365 by bbouvier@mozilla.com at Fri, 28 Sep 2018 07:14:31 +0000
Bug 1490251: Add a pref switch to use Cranelift for wasm compilation; r=luke
7864f125bbcd: Bug 1469027: Integrate Cranelift in Spidermonkey; r=sunfish, r=luke
Benjamin Bouvier <benj@benj.me> - Tue, 11 Sep 2018 17:01:46 +0200 - rev 438646
Push 108365 by bbouvier@mozilla.com at Fri, 28 Sep 2018 07:14:31 +0000
Bug 1469027: Integrate Cranelift in Spidermonkey; r=sunfish, r=luke
355f1ffc8348: Bug 1494134 - clean up ifdefs in wasm::Classify. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 26 Sep 2018 09:59:31 +0200 - rev 438643
Push 108364 by lhansen@mozilla.com at Fri, 28 Sep 2018 06:46:07 +0000
Bug 1494134 - clean up ifdefs in wasm::Classify. r=luke This code is a little messy since we define opcodes unconditionally but switch on them conditionally. Cleaning up ifdefs in previous patches uncovered brittleness here. This patch takes a principled approach: we always test all cases, but whether we succeed with a classification or fail with undefined opcode is hidden inside macros that are subject to feature definitions.
2456b585ef87: Bug 1469027: Introduce a new switch to determine if we should compile with Cranelift; r=luke
Benjamin Bouvier <benj@benj.me> - Fri, 07 Sep 2018 13:45:24 +0200 - rev 438428
Push 108319 by bbouvier@mozilla.com at Thu, 27 Sep 2018 09:36:28 +0000
Bug 1469027: Introduce a new switch to determine if we should compile with Cranelift; r=luke
7df169d72b50: Bug 1469027: Introduce a new switch to determine if we should compile with Cranelift; r=luke
Benjamin Bouvier <benj@benj.me> - Fri, 07 Sep 2018 13:45:24 +0200 - rev 438312
Push 108284 by bbouvier@mozilla.com at Wed, 26 Sep 2018 16:25:52 +0000
Bug 1469027: Introduce a new switch to determine if we should compile with Cranelift; r=luke
f7fd0abf23ce: Bug 1493703 - Remove more fairly safe #ifdef ENABLE_WASM_GC. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 24 Sep 2018 17:13:42 +0200 - rev 438010
Push 108218 by lhansen@mozilla.com at Tue, 25 Sep 2018 08:01:55 +0000
Bug 1493703 - Remove more fairly safe #ifdef ENABLE_WASM_GC. r=luke These are internal functions and members that provide support for the feature: compilation, write barriers, and so on.
e57f4697f91f: Bug 1493703 - Remove truly redundant #ifdef ENABLE_WASM_GC. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 24 Sep 2018 16:07:16 +0200 - rev 438009
Push 108218 by lhansen@mozilla.com at Tue, 25 Sep 2018 08:01:55 +0000
Bug 1493703 - Remove truly redundant #ifdef ENABLE_WASM_GC. r=luke These #ifdefs are nested inside others of the same kind.
01a28ef7dd35: Bug 1493692 - use ValType::Code to validate type code. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 24 Sep 2018 16:58:25 +0200 - rev 438008
Push 108218 by lhansen@mozilla.com at Tue, 25 Sep 2018 08:01:55 +0000
Bug 1493692 - use ValType::Code to validate type code. r=luke
8b553d15956a: Bug 1493475 - Cleanup asm.js parser cleanup. r=luke
Ted Campbell <tcampbell@mozilla.com> - Mon, 24 Sep 2018 19:21:23 -0400 - rev 437994
Push 108207 by tcampbell@mozilla.com at Mon, 24 Sep 2018 23:54:17 +0000
Bug 1493475 - Cleanup asm.js parser cleanup. r=luke
56a2c01222f3: Bug 1459900 - Implement struct.narrow. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 13 Jun 2018 11:18:50 -0700 - rev 437675
Push 108131 by lhansen@mozilla.com at Fri, 21 Sep 2018 17:11:51 +0000
Bug 1459900 - Implement struct.narrow. r=luke Struct.narrow is a slow, structural downcast, meant as a stopgap solution that allows experimenters to begin targeting wasm+gc without waiting for final semantics. The operator will likely be removed eventually in favor of faster, more constrained downcasts and type import/export. See https://github.com/lars-t-hansen/moz-gc-experiments for detailed semantics.
b4bb1edd5539: Bug 1459900 - Implement struct.get and struct.set. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 08 Jun 2018 15:43:11 +0200 - rev 437674
Push 108131 by lhansen@mozilla.com at Fri, 21 Sep 2018 17:11:51 +0000
Bug 1459900 - Implement struct.get and struct.set. r=luke Implement the struct.get and struct.set operators on references of known structure type. See https://github.com/lars-t-hansen/moz-gc-experiments for detailed semantics.
29614e10d512: Bug 1459900 - Implement struct.new. r=luke
Lars T Hansen <lhansen@mozilla.com> - Wed, 09 May 2018 11:35:47 +0200 - rev 437673
Push 108131 by lhansen@mozilla.com at Fri, 21 Sep 2018 17:11:51 +0000
Bug 1459900 - Implement struct.new. r=luke Implement struct.new on wasm structure types. The single form of the struct.new operator requires initializers for all fields and constructs a TypedObject that can also be manipulated by JS. See https://github.com/lars-t-hansen/moz-gc-experiments for detailed (intermediate) semantics.
71ded3ad0ed4: Bug 1479465 - ref.eq on all wasm reference types. r=luke
Lars T Hansen <lhansen@mozilla.com> - Mon, 30 Jul 2018 17:31:08 +0200 - rev 437617
Push 108106 by lhansen@mozilla.com at Fri, 21 Sep 2018 07:49:30 +0000
Bug 1479465 - ref.eq on all wasm reference types. r=luke Implement ref.eq on all wasm pointer types without worrying about implementing eqref yet, with standard prefix-based upcast semantics. See https://github.com/lars-t-hansen/moz-gc-experiments for a detailed description of these (intermediate) semantics.
371ea5445585: Bug 1490993 part 5 - Always use braces for if/for/while statements in js/src/jit/arm64. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 13 Sep 2018 17:17:30 +0000 - rev 436643
Push 107893 by shindli@mozilla.com at Sun, 16 Sep 2018 21:42:55 +0000
Bug 1490993 part 5 - Always use braces for if/for/while statements in js/src/jit/arm64. r=luke Depends on D5765 Differential Revision: https://phabricator.services.mozilla.com/D5766
91fc6c048c07: Bug 1490594 - Always use braces for if/for/while statements in jsapi-tests. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Wed, 12 Sep 2018 14:23:43 +0000 - rev 436038
Push 107782 by dvarga@mozilla.com at Thu, 13 Sep 2018 02:51:12 +0000
Bug 1490594 - Always use braces for if/for/while statements in jsapi-tests. r=luke Differential Revision: https://phabricator.services.mozilla.com/D5649
ec5fe5d123b1: Bug 1490594 - Always use braces for if/for/while statements in jsapi-tests. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Wed, 12 Sep 2018 14:23:43 +0000 - rev 435970
Push 107758 by dluca@mozilla.com at Wed, 12 Sep 2018 18:37:29 +0000
Bug 1490594 - Always use braces for if/for/while statements in jsapi-tests. r=luke Differential Revision: https://phabricator.services.mozilla.com/D5649
20142eb6afd6: Bug 1488698 - Always use braces for if/for/while statements in js/src/wasm, part 4. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 06 Sep 2018 11:26:16 +0200 - rev 435720
Push 107708 by jandemooij@gmail.com at Tue, 11 Sep 2018 14:33:28 +0000
Bug 1488698 - Always use braces for if/for/while statements in js/src/wasm, part 4. r=luke
ab68962c6c3f: Bug 1488698 - Always use braces for if/for/while statements in js/src/wasm, part 3. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 06 Sep 2018 11:25:07 +0200 - rev 435719
Push 107708 by jandemooij@gmail.com at Tue, 11 Sep 2018 14:33:28 +0000
Bug 1488698 - Always use braces for if/for/while statements in js/src/wasm, part 3. r=luke
78d8957d12e2: Bug 1488698 - Always use braces for if/for/while statements in js/src/vm, part 4. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 06 Sep 2018 11:13:06 +0200 - rev 435708
Push 107708 by jandemooij@gmail.com at Tue, 11 Sep 2018 14:33:28 +0000
Bug 1488698 - Always use braces for if/for/while statements in js/src/vm, part 4. r=luke
b7954f956259: Bug 1469027: Move wasm types shared with Cranelift in a WasmBinaryConstants.h; r=luke
Benjamin Bouvier <benj@benj.me> - Fri, 07 Sep 2018 18:30:06 +0200 - rev 435467
Push 107649 by bbouvier@mozilla.com at Mon, 10 Sep 2018 14:42:41 +0000
Bug 1469027: Move wasm types shared with Cranelift in a WasmBinaryConstants.h; r=luke
9347f5a5365d: Bug 1469027: Add a --wasm-force-cranelift flag to the shell; r=luke
Benjamin Bouvier <benj@benj.me> - Fri, 07 Sep 2018 13:42:16 +0200 - rev 435466
Push 107649 by bbouvier@mozilla.com at Mon, 10 Sep 2018 14:42:41 +0000
Bug 1469027: Add a --wasm-force-cranelift flag to the shell; r=luke
e951ad8147a7: Bug 722345 part 3 - Remove request API. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 28 Aug 2018 09:53:30 +0200 - rev 434750
Push 107484 by jandemooij@gmail.com at Wed, 05 Sep 2018 09:11:37 +0000
Bug 722345 part 3 - Remove request API. r=luke Differential Revision: https://phabricator.services.mozilla.com/D4424
8542dc7212b4: Bug 722345 part 2 - Remove AutoCheckRequestDepth, rename CHECK_REQUEST to CHECK_THREAD. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 28 Aug 2018 10:02:11 +0200 - rev 434749
Push 107484 by jandemooij@gmail.com at Wed, 05 Sep 2018 09:11:37 +0000
Bug 722345 part 2 - Remove AutoCheckRequestDepth, rename CHECK_REQUEST to CHECK_THREAD. r=luke Differential Revision: https://phabricator.services.mozilla.com/D4423
6f17ffaad886: Bug 722345 part 1 - Remove now unused activity callback API. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 28 Aug 2018 09:19:17 +0200 - rev 434748
Push 107484 by jandemooij@gmail.com at Wed, 05 Sep 2018 09:11:37 +0000
Bug 722345 part 1 - Remove now unused activity callback API. r=luke Differential Revision: https://phabricator.services.mozilla.com/D4422
e99f9ea18046: Bug 1487327 - Custom section for opting in to GC feature work. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 31 Aug 2018 08:50:24 +0200 - rev 434743
Push 107480 by lhansen@mozilla.com at Wed, 05 Sep 2018 08:10:35 +0000
Bug 1487327 - Custom section for opting in to GC feature work. r=luke We introduce a new numbered section which must be the first section in the .wasm file if it is present at all. This section, GcFeatureOptIn, carries the version number of the GC feature the module wants to opt in to. During validation we signal an error if we can't satisfy the requirement; and we signal errors for all the GC feature aspects (anyref, ref, struct, and all the ref-type instructions) if no opt-in section was present. This patch does not affect how we generate code for stubs; that code is controlled by the --wasm-gc flag, as it is module-independent. This patch also does not change how we choose the compiler; that is still based on --wasm-gc. But once --wasm-gc disappears we will be using the opt-in section to control compiler selection until Ion can support the GC feature. Currently the only supported GC feature version is 1. As the engine evolves to accomodate new versions we will accept old version numbers provided the engine remains completely backward compatible. (We can also provide version-triggered backward compatibility but I question the utility.)
6029e0377dda: Bug 1487238 - Do realm checks instead of compartment checks in the expression decompiler code. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Tue, 04 Sep 2018 14:07:28 +0000 - rev 434696
Push 107467 by btara@mozilla.com at Tue, 04 Sep 2018 23:45:57 +0000
Bug 1487238 - Do realm checks instead of compartment checks in the expression decompiler code. r=luke Another option is to allow same-compartment realms here, but this seems simpler and safer (to ensure we don't leak any information in document.domain cases or if we ever change from CPO to something else). A principals check is probably not worth the complexity. Differential Revision: https://phabricator.services.mozilla.com/D4868
c91d997687bf: Bug 1487327 - Custom section for opting in to GC feature work. r=luke
Lars T Hansen <lhansen@mozilla.com> - Fri, 31 Aug 2018 08:50:24 +0200 - rev 434463
Push 107381 by lhansen@mozilla.com at Mon, 03 Sep 2018 12:27:09 +0000
Bug 1487327 - Custom section for opting in to GC feature work. r=luke We introduce a new numbered section which must be the first section in the .wasm file if it is present at all. This section, GcFeatureOptIn, carries the version number of the GC feature the module wants to opt in to. During validation we signal an error if we can't satisfy the requirement; and we signal errors for all the GC feature aspects (anyref, ref, struct, and all the ref-type instructions) if no opt-in section was present. This patch does not affect how we generate code for stubs; that code is controlled by the --wasm-gc flag, as it is module-independent. This patch also does not change how we choose the compiler; that is still based on --wasm-gc. But once --wasm-gc disappears we will be using the opt-in section to control compiler selection until Ion can support the GC feature. Currently the only supported GC feature version is 1. As the engine evolves to accomodate new versions we will accept old version numbers provided the engine remains completely backward compatible. (We can also provide version-triggered backward compatibility but I question the utility.)
653e1282f4ce: Bug 1481793 part 5 - Use JSObject::nonCCWRealm instead of JSObject::deprecatedRealm in JSContext::enterRealmOf. r=luke
Jan de Mooij <jdemooij@mozilla.com> - Thu, 30 Aug 2018 09:27:10 +0200 - rev 434050
Push 107243 by jandemooij@gmail.com at Thu, 30 Aug 2018 12:56:41 +0000
Bug 1481793 part 5 - Use JSObject::nonCCWRealm instead of JSObject::deprecatedRealm in JSContext::enterRealmOf. r=luke