Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
When breaking out of nested for-of loops, we emit code to close each of the iterators, and we cover each of those code segments with an individual FOR_OF_ITERCLOSE trynote. When TryNoteIter walks through the trynotes, it sees a single FOR_OF_ITERCLOSE trynote at the current pc, and skips past one enclosing for-of. This is insufficient for the case where an outer iterator throws an exception while being closed.
This patch fixes that problem. The new semantics for FOR_OF_ITERCLOSE trynotes are: a FOR_OF_ITERCLOSE trynote begins as soon as we clear ther iterator slot on the stack, and continues until we leave the scope. It indicates that the innermost unclosed for-of iterator has been closed. Nested FOR_OF_ITERCLOSE trynotes indicate that nested for-of iterators have been closed.
This is my first patch touching the frontend, so it's probably horribly unidiomatic. I am open to suggestions for better ways to structure this.
Differential Revision: https://phabricator.services.mozilla.com/D26572
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
This patch ensures that once the ClearTree task is run on the updater
thread, we throw away any other remaining tasks in the queue, as they
will never get run. (Note that the ClearTree task removes the APZUpdater
instance from the global map, and so it becomes "unfindable", meaning
the ProcessQueue will never run again on that instance).
Differential Revision: https://phabricator.services.mozilla.com/D26541
--HG--
extra : moz-landing-system : lando
Produces a help text that conforms to the line width recommendations
of nsICommandLine.
On the other hand, the formatting of the source code itself is
rendered rather ugly by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D26583
--HG--
extra : moz-landing-system : lando
Instead of:
perl gen_template.pl -b=123456 --type=plain > path/to/test_bug123456.html
You can do:
./mach addtest --suite="mochitest-plain" > path/to/test_bug123456.html
But you can also pass in a new file path and let it guess the suite/doc:
```
# mochitest-chrome tests
./mach addtest js/xpconnect/tests/chrome/test_chrome.html
./mach addtest js/xpconnect/tests/chrome/test_chrome.xhtml
./mach addtest js/xpconnect/tests/chrome/test_chrome.xul
# mochitest-plain tests
./mach addtest js/xpconnect/tests/mochitest/test_plain.html
./mach addtest js/xpconnect/tests/mochitest/test_plain.xhtml
./mach addtest js/xpconnect/tests/mochitest/test_plain.xul
# mochitest-browser tests
./mach addtest browser/base/content/test/alerts/browser_foo.js
# xpcshell tests
./mach addtest browser/components/extensions/test/xpcshell/test_xpcshell.js
```
This also changes the mochitest template files in the following ways:
- removes the bug # boilerplate
- remove some unnecessary attributes in the template
- removes the th.template
- adds the browser.template for browser-chrome tests
Differential Revision: https://phabricator.services.mozilla.com/D25482
--HG--
rename : testing/mochitest/static/chrome.template.txt => testing/mochitest/static/chromehtml.template.txt
rename : testing/mochitest/static/test.template.txt => testing/mochitest/static/plainhtml.template.txt
rename : testing/mochitest/static/xhtml.template.txt => testing/mochitest/static/plainxhtml.template.txt
rename : testing/mochitest/static/xul.template.txt => testing/mochitest/static/plainxul.template.txt
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
Quick fix for python3 mozbase perma-fail on osx: Use python 3.6 explicitly, rather
than the system default 3.7, which appears to be broken currently (lacking ssl support).
Differential Revision: https://phabricator.services.mozilla.com/D26345
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
To verify that I had covered all of the existing functionality, I added assertions to DoCallFallback and DoSpreadCallFallback to verify that the old C++ implementation never managed to attach a stub if CacheIR had failed to handle it. This patch includes the changes made as a result of this testing:
1. JSOP_CALLITER is equivalent to JSOP_CALL for our purposes. Adding support for JSOP_CALLITER did not require any additional changes.
2. JSOP_SUPERCALL and JSOP_SPREADSUPERCALL are just like normal constructors, except we don't save a template object. I added the super guards where necessary.
3. There were also a number of cases where we tried to attach a CacheIR stub, declined to attach because an identical stub already existed, and then attached an old stub. For example, a spread call IC with more than 16 arguments will fail, but we will try to attach another spread call IC. I examined the failures of this sort by hand. Many of them were invalid (in particular, oomtests that caused us to fail during the process of attaching the stub) or seemed acceptable. I made a few spot fixes to cover easy exceptions.
4. I added jitspew to the attachment code to print BaselineICFallback messages if we try to attach an identical stub, which will hopefully help when testing new ICs to verify that they are not perma-failing.
Differential Revision: https://phabricator.services.mozilla.com/D25877
--HG--
extra : moz-landing-system : lando
This patch adds support for ConstStringSplit. ConstStringSplit is attached after the call is performed, so that it can grab and cache the result. To make it work, I added a new AttachDecision value.
Note:
1. Testing this code made me realize that a previous change I made was wrong. Even in call ICs that don't use argc, we have to initialize the input location. If we don't, the register can be allocated and clobbered, which will break subsequent ICs.
2. We only want a ConstStringSplit if this is the first stub that we try attaching. (If there's already another stub, then it can't be a constant string split. The old implementation would remove any existing ConstStringSplit stubs when it realized that the optimization had failed, but there isn't a particularly nice way of doing that in CacheIR and I don't think it matters much.
3. For unclear reasons, we had an implementation of CallStringSplitResult in IonCacheIRCompiler. It was dead code, so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D25876
--HG--
extra : moz-landing-system : lando
In some cases we want to avoid attaching a stub, but not count it as a failure. To make it easier to express this (as well as deferred stubs, which will be used to implement ConstStringSplit in a future patch), I rewrote all the tryAttachFoo stubs in CallIRGenerator to return an enum instead of a bool. (This seems better than a bunch of mutually exclusive boolean out-params.)
Differential Revision: https://phabricator.services.mozilla.com/D25875
--HG--
extra : moz-landing-system : lando
This patch extends megamorphic support to native functions, which were not previously supported.
Differential Revision: https://phabricator.services.mozilla.com/D25874
--HG--
extra : moz-landing-system : lando
This patch moves CallAnyScripted over to CacheIR.
Most of the pieces were already in place to implement FunCall/FunApply. The only new CacheIR op is GuardFunctionIsConstructor. I also took the opportunity to refactor the masm function flag code a little bit.
Differential Revision: https://phabricator.services.mozilla.com/D25873
--HG--
extra : moz-landing-system : lando
This patch moves ScriptedApplyArgs and ScriptedApplyArray to CacheIR, and adds NativeApplyArgs and NativeApplyArray.
Like a spread call, FunApply updates argc as part of the call op, after we've passed all the guards.
Comparisons:
- The new code in BaselineCacheIRCompiler::updateArgc corresponds to parts of ICCallStubCompiler::guardFunApply.
- BaselineCacheIRCompiler::emitGuardFunApply also corresponds to ICCallStubCompiler::guardFunApply.
- BaselineCacheIRCompiler::pushFunApplyArgs corresponds to ICCallStubCompiler::pushCallerArguments
- BaselineCacheIRCompiler::pushFunApplyArray corresponds to ICCallStubCompiler::pushArrayArguments
- CallIRGenerator::tryAttachFunApply corresponds to TryAttachFunApplyStub + ICCall_ScriptedApplyArray::Compiler::generateStubCode
Differential Revision: https://phabricator.services.mozilla.com/D25872
--HG--
extra : moz-landing-system : lando
This patch adds support for FunCall with a native target, which the old implementation lacked.
Notes:
1. MacroAssembler::branchIfInterpreted had been unused for quite a while. I updated it to match MacroAssembler::branchIfFunctionHasNoJitEntry (and check WASM_OPTIMIZED in the non-constructor case).
2. GuardIsNativeFunction was a confusing name, especially after I added GuardFunctionIsNative. I renamed GuardIsNativeFunction to GuardSpecificNativeFunction to better represent what it does.
3. Native function calls in the simulator need to be wrapped up to trigger a software interrupt. To call an arbitrary native function, we need a trampoline, so I added CallAnyNative.
Differential Revision: https://phabricator.services.mozilla.com/D25871
--HG--
extra : moz-landing-system : lando
This patch adds support for scripted fun_call.
The old logic is in TryAttachFunCallStub and ICCall_ScriptedFunCall::Compiler::generateStubCode.
Differential Revision: https://phabricator.services.mozilla.com/D25870
--HG--
extra : moz-landing-system : lando
The initial implementation of CacheIR spread calls added a guardAndUpdateSpreadArgc op, which had to be emitted just before the call. This patch moves the argc update inside the call op, where it belonged all along.
In a few patches, fun_apply will also use this code.
Differential Revision: https://phabricator.services.mozilla.com/D25869
--HG--
extra : moz-landing-system : lando
- Doing my best to unify some of this code and provide a single-ish source of truth for things.
1. Add a "CallFlags" struct that bundles up information about the call, including whether it is a constructor, whether it is a cross-realm call, and how its arguments are being passed. Notes:
a) After working with it for a while, I'm convinced that isCrossRealm is named backwards. Calls are cross-realm by default. I've changed the flag to isSameRealm so that now we only have to set a non-default value for the flag if we know something about the callee. This makes CallFlags noticeably more ergonomic.
b) Right now there are two possibilities for how arguments are being passed: standard and spread. In future patches, this will expand to include FunCall, FunApplyArgs, and FunApplyArray.
c) This all gets packed up into a byte to make it easy to pass via CacheIR.
2. Unify as much of the argument-address-calculating logic in one place. I've added an ArgumentKind enum that lets us ask for this, callee, newtarget, arg0, or arg1, and then it calculates the slot, possibly using argc.
3. The first consumer of GetIndexFromArgumentKind is a new CacheIR interface for accessing specific arguments. Instead of doing manual calculations and using LoadStackValue(slotIndex), we use LoadArgument(argumentKind, argcInfo). The correct slot is calculated under the covers and encoded in the cache op. Note that sometimes we are willing to bake in argc at compile time (for example, tryAttachStringSplit) and other times we want the flexibility / codesharing of using the value of argc that we get as an input operand. To make this work, both LoadArgument and the CacheIR op it generates come in two flavours. I'm very open to bikeshedding on the name, which is currently borrowing terminology from LoadEnvironment(Fixed/Variable)SlotResult.
4. The second consumer of GetIndexFromArgumentKind is a new BaselineCacheIRCompiler-internal interface for loading objects off the stack, because it happens pretty often. Right now, the user of the interface is responsible for tracking the depth of the stack above the arguments, although I'd like to find a way to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D25868
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
ImageEncoder::ExtractDataInternal takes a `const nsAString&` for its
options, but flattens it into a null-terminated `nsString` so callees
can take a `char16_t*`. But nearly all of those callees eventually wind
up calling ImageEncoder::GetInputStream, which just constructs an
`nsDependentString` from the passed character pointer.
There's no reason to do all this extra work. We can just pass the
original options reference all the way through the stack and avoid
needless conversions.
Differential Revision: https://phabricator.services.mozilla.com/D26353
--HG--
extra : moz-landing-system : lando
We already have a null-terminated `nsString` in this code; we don't need
to turn it into another null-terminated `nsString`.
Depends on D26355
Differential Revision: https://phabricator.services.mozilla.com/D26356
--HG--
extra : moz-landing-system : lando
We flatten an nsAString before calling GetPublicKey, but GetPublicKey
doesn't actually care about whether the string is null-terminated or
not. Let's save a tiny amount of work by not doing the flattening.
Differential Revision: https://phabricator.services.mozilla.com/D26355
--HG--
extra : moz-landing-system : lando
mJavaDecoder is invalid after the decoder is shut down and should never
be used.
Differential Revision: https://phabricator.services.mozilla.com/D26438
--HG--
extra : moz-landing-system : lando
