As the following commit explained, this change isn't backwards compatible with
the existing implementation and the spec tests needed to be modified.
I've written a stub commit to the spec interpreter to encode/decode element
segments well enough to pass the current spec tests, and did another
import of the tests. The commit can be found here [1] [2].
[1] https://github.com/eqrion/spec/tree/spidermonkey-tree-tests
[2] d81e3cfe6e
Differential Revision: https://phabricator.services.mozilla.com/D40584
--HG--
extra : moz-landing-system : lando
The element segment changes are backwards compatible with the MVP, but not the
existing implementation. Some tests needed to update their expectations or
binary encoding.
Differential Revision: https://phabricator.services.mozilla.com/D40583
--HG--
extra : moz-landing-system : lando
Issue: https://github.com/WebAssembly/bulk-memory-operations/issues/98
This commit updates the encoding of element segments to the latest bulk-memory
proposal. This is backwards compatible with the MVP, but a breaking change from
the previously implemented bulk-memory spec.
The following semantic differences are made with the new encoding.
1. The introduction of 'Declared' segments
* Declared segments allow a Wasm module to forward declare which
functions are aliasable by ref.func. See reference-types#31 for more
information.
2. Whether an element expression or function indices are encoded now depends
on an independent flag from the 'kind' of an element segment.
3. The definition kind or element expression type is now explicitly encoded
in the element segment.
Differential Revision: https://phabricator.services.mozilla.com/D40582
--HG--
extra : moz-landing-system : lando
Issue: https://github.com/WebAssembly/bulk-memory-operations/issues/98
This commit updates the decoding of element segments to the latest bulk-memory
proposal. This is backwards compatible with the MVP, but a breaking change from
the previously implemented bulk-memory spec.
The following semantic differences are made with the new encoding.
1. The introduction of 'Declared' segments
* Declared segments allow a Wasm module to forward declare which
functions are aliasable by ref.func. See reference-types#31 for more
information.
2. Whether an element expression or function indices are encoded now depends
on an independent flag from the 'kind' of an element segment.
3. The definition kind or element expression type is now explicitly encoded
in the element segment.
A following commit will update the in-tree wat2wasm encoder.
Differential Revision: https://phabricator.services.mozilla.com/D40581
--HG--
extra : moz-landing-system : lando
There are about the same number of occurrences of "ENABLE_INTL_API" and "EXPOSE_INTL_API"
in the tree, so preferring one over the other doesn't lead to fewer changes. Therefore
I went with "ENABLE_INTL_API", because "ENABLE_" (resp. "MOZ_ENABLE") is already used as
the prefix for other preprocessor ifdef's.
Differential Revision: https://phabricator.services.mozilla.com/D41188
--HG--
extra : moz-landing-system : lando
The gczeal test change was added because to make it more deterministic, after
it started failing in automation following this change.
Differential Revision: https://phabricator.services.mozilla.com/D40650
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Off-thread tasks now use a pool of JSContexts (for compatibility with the XPCOM thread pool).
Tasks that don't need a JSContext can run without one (nullptr TlsContext). We can now do this
for Ion and Wasm tasks too.
Depends on D41380
Differential Revision: https://phabricator.services.mozilla.com/D41381
--HG--
extra : moz-landing-system : lando
Some functions that are called from the Ion backend use AutoUnsafeCallWithABI.
Initially I wanted to fix this by splitting these functions in two separate
functions, but this doesn't work well for all the Math builtins that are called
by GVN.
Depends on D41379
Differential Revision: https://phabricator.services.mozilla.com/D41380
--HG--
extra : moz-landing-system : lando
This will allow us to run off-thread Ion tasks without a JSContext.
I renamed IonCompiling and IonCompilation to IonBackend to make it
clearer that this doesn't include IonBuilder time.
Differential Revision: https://phabricator.services.mozilla.com/D41379
--HG--
extra : moz-landing-system : lando
Because DebugTrapEntries are only present if the script has debugger instrumentation
it should be fine to store this as a simple list of entries.
Differential Revision: https://phabricator.services.mozilla.com/D40948
--HG--
extra : moz-landing-system : lando
These tests both load a page, create some chrome reference to it, then
navigate to another page to cause a window close on the original page,
then check to make sure the references to the original page have gone
away.
With Fission, if the navigation is cross-process, then the message
manager gets torn down in the original process where the browser test
is running, and the sendAsyncMessage call in content-task.js fails
with the cryptic error NS_ERROR_ILLEGAL_VALUE.
This can be fixed by making the navigation not be cross-origin. The
test only wants the original pages to be torn down. The origin of the
new page doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D41408
--HG--
extra : moz-landing-system : lando
These changes were produced using the Include What You Use tool, which uses the
Clang front end to figure out which headers actually declare the identifiers
you're using.
These changes aren't exactly the ones IWYU suggests. The tool has some odd false
positives, even when you use its 'pragmas' to tell it about headers like
jsapi.h, which is supposed to gather up other headers for you. And there are
some cases where I could get away with a forward declaration (say, for Maybe),
but I really just want to #include the full header because it seems better. But
overall this patch has only minor deviations from IWYU's suggestions.
No intended change in execution or visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D39446
--HG--
extra : moz-landing-system : lando
Finally, once we know the type of the map we're consulting, that tells us all
the other types we need to know: certainly the referent and wrapper types, but
also the referent variant type, via the wrapper.
DebuggerWeakMap does need new member types to tell us what its Referent and
Wrapper types are. Rename the type parameters to avoid shadowing.
Since the map type can be inferred from the call, we no longer need to pass any
type parameters at all when we call the innermost wrapVariantReferent overload.
Differential Revision: https://phabricator.services.mozilla.com/D38544
--HG--
extra : moz-landing-system : lando
For generatorFrames, this doesn't matter, but for sources, subsequent patches
need a more precise Referent type than simply 'JSObject'.
Any type used as a weak map key needs a MovableCellHasher instantiation, so add
the necessary ones to Barrier.cpp. Since the list is getting long, sort it.
Differential Revision: https://phabricator.services.mozilla.com/D38543
--HG--
extra : moz-landing-system : lando
It's more convenient for a DebuggerWeakMap's Wrapper type parameter to be the
pointed-to type, not the pointer type, since we'll be consulting its member
types. Then, it's a bit more consistent to also use the pointed-to type for
Referent.
Differential Revision: https://phabricator.services.mozilla.com/D38542
--HG--
extra : moz-landing-system : lando
Give DebuggerScript and DebuggerSource a member type that spells out the variant
type appropriate for their referents. This allows wrapVariantReferent to simply
consult the wrapper for the referent variant type instead of demanding it as a
type parameter.
No intended change in visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D38541
--HG--
extra : moz-landing-system : lando
Technically, DebuggerWeakMap could be used for any sort of cross-compartment
mapping. But we actually only use it for looking up Debugger reflection objects,
so it is more informative to call the key and value types 'referent' and
'wrapper'.
No intended change in visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D38540
--HG--
extra : moz-landing-system : lando
Give DebuggerWeakMap a `Wrapper` type parameter to use as the WeakMap value type
instead of plain JSObject*. Then, supply a specific wrapper class type for each
DebuggerWeakMap instantiation.
No intended change in visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D38539
--HG--
extra : moz-landing-system : lando
This adds js/src/dbg/Source.{cpp,h}, and moves DebuggerSource's definition
there. No intended change in implementation or visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D38538
--HG--
extra : moz-landing-system : lando
This moves the string wrapper map to the zone where it's shared by all compartments in the zone.
Differential Revision: https://phabricator.services.mozilla.com/D41366
--HG--
extra : moz-landing-system : lando
Encapsulate manipulation of bytecode within RemoveReferenceNames method using accessor classes BytecodeLocation and BytecodeIterator
Differential Revision: https://phabricator.services.mozilla.com/D41120
--HG--
extra : moz-landing-system : lando
This splits off string wrappers into a separate table with a different type (because we don't need to keep a separate sub table per compartment).
Differential Revision: https://phabricator.services.mozilla.com/D41183
--HG--
extra : moz-landing-system : lando
