This patch integrates the majority of the mach-perftest-notebook project from the github project to the in-tree mozperftest package/tool. Certain portions of it are disabled in this integration (posting to iodide, and transform searching).
Differential Revision: https://phabricator.services.mozilla.com/D70134
--HG--
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
This solves an edge case where tab completing a Python 2 command with global
arguments was using the wrong Python version.
Differential Revision: https://phabricator.services.mozilla.com/D56445
--HG--
extra : moz-landing-system : lando
This works for me and should allow trees to reopen.
Differential Revision: https://phabricator.services.mozilla.com/D70415
--HG--
extra : histedit_source : 529e1cb5cdb3030f145f44fc1ebf0ea9ae00aa8f
As noted by Jamie, accessible labels for richlistitem elements come from the
label elements that have value attributes within them.
In bug 1608202, we accidentally reused the same fluent message for the buttons
in about:downloads and the library download view (DownloadsViewUI.jsm) and
the context menuitems that do the same thing. This meant that
those menuitems gained a tooltip they shouldn't have, and the buttons gained
a label and accesskey they shouldn't have. The latter caused the
accessibility regression described in the bug.
This patch separates out the two usecases for the same string. I also checked
the other l10nIds used in DownloadsViewUI.jsm, and as far as I can tell this
is the only one that is reused in this way.
Differential Revision: https://phabricator.services.mozilla.com/D70219
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
Most (all?) mach xpcshell-test calls result in calling install_tests(None) while
most mach test calls for the same test/directory result in calling install_tests()
with a collection of test objects. Providing test objects allows install_tests()
to optimize which tests are installed, but there have been several recent bugs
that appear to be related to that optimization. Let's rely less on that optimization
and make things consistent between test/xpcshell-test. (There's a parallel
consideration for test vs mochitest.)
Differential Revision: https://phabricator.services.mozilla.com/D70052
--HG--
extra : moz-landing-system : lando
Update code in a few places to work with Python 3, especially with regard to how we invoke subprocesses with text output. Note that the Marionette test harness code needs to be updated so that text is written out in the correct encoding (see bug 1615748).
Differential Revision: https://phabricator.services.mozilla.com/D69012
--HG--
extra : moz-landing-system : lando
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
ConfigureSandbox._implied_options is a list of ReadOnlyNamespaces.
In python 3.5, ReadOnlyNamespaces end up with no guarantee in the order
of their __dict__. So when comparing
ReadOnlyNamespace(a=1, b=2)
and
ReadOnlyNamespace(a=3, b=4)
It's not guaranteed that the a's are compared before the b's.
In ConfigureSandbox._implied_options, some of those ReadOnlyNamespace
fields are SandboxDependsFunctions, which actually raise an error when
they're being compared, because we don't want that to happen in the
sandbox.
So when using python 3, configure would randomly fail when trying to
remove items from the ConfigureSandbox._implied_options list because
removing an item from a list scans the list to find the first element
that matches.
And ConfigureSandbox._implied_options needs to be ordered, which is why
it's currently a list.
So instead of removing by value, we create a new list with the remaining
values. But because the loop recurses, and needs the updated list, we
filter first.
Differential Revision: https://phabricator.services.mozilla.com/D69535
--HG--
extra : moz-landing-system : lando
When the build is stalled for some random reason, and mach executed a
python subcommand (this may or may not be limited to python 3, I'm not
sure, and it doesn't really matter since it's a problem on python 3,
which matters most), the subcommand may not have actually sent its last
bits of output before the stall because its output is a pipe and in that
case python uses buffered outputs.
Now, when your build is completely stalled and you ctrl+C, you end up
without these bits of output, and in some cases, those bits of output
can contain actual information, like... tracebacks.
A real life example of this is bug 1624670 when running mach build or
mach configure with the patches from bug 1627163 applied, and configure
stalls without printing out the ValueError message at all.
Differential Revision: https://phabricator.services.mozilla.com/D69925
--HG--
extra : moz-landing-system : lando
The effect of the deleted code has been to not install required head files
when those head files are not in the same directory as the test's manifest;
that seems wrong. I am slightly concerned about the comment justifying the
short-cut, but I cannot find any ill effect from removing the code, and doing
so allows test_attachments_downloader.js to run with either xpcshell-test or test.
Differential Revision: https://phabricator.services.mozilla.com/D70051
--HG--
extra : moz-landing-system : lando
Support for python 2 is completely dropped. It wouldn't be too much code
to support both python 2 and 3 but since configure is going to switch to
python 3 shortly after, it's not worth the effort.
Differential Revision: https://phabricator.services.mozilla.com/D69525
--HG--
extra : moz-landing-system : lando
