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.
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
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
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
This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
