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
This removes Compartment::WrapperEnum and renames NonStringWrapperEnum so there's now just ObjectWrapperEnum and StringWrapperEnum.
In js::VisitGrayWrapperTargets, strings can never be marked gray and so needn't be considered. In JS::TraceIncomingCCWs, strings have no compartment and so can be ignored here too.
Differential Revision: https://phabricator.services.mozilla.com/D41182
--HG--
extra : moz-landing-system : lando
The object of this set of patches is to remove CrossCompartmentKey and have the hashtable key be either JSObject* or JSString* as appropriate. Wrappers for strings and objects are already stored in separate tables since currently we use a table per target compartment with strings in the nullptr compartment.
The first patch removes lookup APIs that take CrossCompartmentKeys and Values.
Differential Revision: https://phabricator.services.mozilla.com/D41180
--HG--
extra : moz-landing-system : lando
My previous change to the format of the new script initializer list broke this because it relies on finding the sentinel value at the end of the list to know that it didn't break out of the loop early. This means we always call NativeObject::rollbackProperties after this loop when we shouldn't.
The symptom of this is that the workspace property of a Blockly.BlockSvg object becomes undefined causing an infinite loop in code that tries to remove it from that workspace. I verified that the patch fixes this problem.
Differential Revision: https://phabricator.services.mozilla.com/D41249
--HG--
extra : moz-landing-system : lando
Steve Fink
André Bargull
Andy Wingo
Benjamin Bouvier
Jon Coppeard
Oana Pop Rus
Henri Sivonen
Paul Bone
Jan de Mooij
Andrew McCreight
Jim Blandy
Will Hawkins
kellykc72