This does the following:
- It introduces a controlling ifdef ENABLE_WASM_REFTYPES that enables
exactly those features that are in the reftypes proposal, excluding
those in the gc proposal. Any remaining features (namely, ref.eq,
(ref T) types, struct types) are still under ENABLE_WASM_GC control.
ENABLE_WASM_GC requires ENABLE_WASM_REFTYPES and this is checked.
- It introduces a new TestingFunctions predicate, wasmReftypesEnabled,
that distinguishes reftype-proposal support from gc-proposal
support. We keep wasmGcEnabled to test for gc-proposal support.
- It segregates test cases so that gc-proposal relevant tests are in
their own files, and tests relevant to the reftypes-proposal are now
guarded by wasmReftypesEnabled.
- It renames the predicate HasGcSupport() as HasReftypesSupport(),
since that is what the predicate tests for.
- It has a drive-by fix for the DEBUG-only function wasm::Classify()
to properly put ref.null and ref.is_null under ifdef control.
Reftypes will soon be enabled unconditionally in Nightly (once we can
trace pointers from Ion frames) while gc-types will remain conditional
until Ion supports all the new instructions for struct types. Therefore:
- The command line switch and about:config option are still called
--wasm-gc and j.o.wasm_gc, respectively, which is fine since they will
fairly soon control only gc-proposal features.
- Internal names still use "Gc" rather than "Reftypes", eg,
HasGcTypes, wasmGc_, and so on. This is most appropriate since it
reduces the scope of the patch and these names will pertain mainly
to the gc feature in the future.
--HG--
extra : rebase_source : 51cf3bfe67da594e89195472e4ce1ccfa36c146d
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This code races with the WeakWorkerRef shutdown code that sets both `mWorkerState` and `mWorkerPrivate` (though on different threads). This patch is based on the observation that except for failure cases, we can't get to `RuntimeServiceWorker::UnregisterWorker` without having already notified the `WorkerRef`s.
Differential Revision: https://phabricator.services.mozilla.com/D14176
--HG--
extra : moz-landing-system : lando
It's possible for RuntimeService to be created after 'xpcom-shutdown' has fired. In this case, it
will receive 'xpcom-shutdown-threads' and perform Cleanup() but not Shutdown(). This means that
mShuttingDown will not be set to 'true', but mIdleThreadTimer will be destroyed. This can cause
crashes if a NoteIdleThread callback runs after Cleanup(). This has been observed to happen in
xpcshell tests.
I think the easiest way to handle this is to manually call Shutdown() in Cleanup() when we
see that mShuttingDown == false. This means that Shutdown() might be called in GetOrCreateService()
if we fail to create the service, but it looks like the code can handle this.
Differential Revision: https://phabricator.services.mozilla.com/D10288
--HG--
extra : source : e28fa79bc2f94ca3b72456b47353f2e2dda8da1a
extra : amend_source : f09508b5c62fb1fe4b5997f822b5d4e5f7ef8076
It's possible for RuntimeService to be created after 'xpcom-shutdown' has fired. In this case, it
will receive 'xpcom-shutdown-threads' and perform Cleanup() but not Shutdown(). This means that
mShuttingDown will not be set to 'true', but mIdleThreadTimer will be destroyed. This can cause
crashes if a NoteIdleThread callback runs after Cleanup(). This has been observed to happen in
xpcshell tests.
I think the easiest way to handle this is to manually call Shutdown() in Cleanup() when we
see that mShuttingDown == false. This means that Shutdown() might be called in GetOrCreateService()
if we fail to create the service, but it looks like the code can handle this.
Differential Revision: https://phabricator.services.mozilla.com/D10288
--HG--
extra : rebase_source : 3c4a9cb76b81c4aef87b6373548e9da8ca64075e
extra : amend_source : d17d7a0e35e8bd9fcfbbd567e387d9af857bfd8a
The patch in the next part will need a handle to the object in
TryPreserveWrapper.
Differential Revision: https://phabricator.services.mozilla.com/D6197
--HG--
extra : moz-landing-system : lando
