In two different places we've been encountering issues regarding 1) how we configure the system Python environment and 2) how the system Python environment relates to the `virtualenv`s that we use for building, testing, and other dev tasks. Specifically:
1. With the push to use `glean` for telemetry in `mach`, we are requiring (or rather, strongly encouraging) the `glean_sdk` Python package to be installed with bug 1651424. `mach bootstrap` upgrades the library using your system Python 3 in bug 1654607. We can't vendor it due to the package containing native code. Since we generally vendor all code required for `mach` to function, requiring that the system Python be configured with a certain version of `glean` is an unfortunate change.
2. The build uses the vendored `glean_parser` for a number of build tasks. Since the vendored `glean_parser` conflicts with the globally-installed `glean_sdk` package, we had to add special ad-hoc handling to allow us to circumvent this conflict in bug 1655781.
3. We begin to rely more and more on the `zstandard` package during build tasks, this package again being one that we can't vendor due to containing native code. Bug 1654994 contained more ad-hoc code which subprocesses out from the build system's `virtualenv` to the SYSTEM `python3` binary, assuming that the system `python3` has `zstandard` installed.
As we rely more on `glean_sdk`, `zstandard`, and other packages that are not vendorable, we need to settle on a standard model for how `mach`, the build process, and other `mach` commands that may make their own `virtualenv`s work in the presence of unvendorable packages.
With that in mind, this patch does all the following:
1. Separate out the `mach` `virtualenv_packages` from the in-build `virtualenv_packages`. Refactor the common stuff into `common_virtualenv_packages.txt`. Add functionality to the `virtualenv_packages` manifest parsing to allow the build `virtualenv` to "inherit" from the parent by pointing to the parent's `site-packages`. The `in-virtualenv` feature from bug 1655781 is no longer necessary, so delete it.
2. Add code to `bootstrap`, as well as a new `mach` command `create-mach-environment` to create `virtualenv`s in `~/.mozbuild`.
3. Add code to `mach` to dispatch either to the in-`~/.mozbuild` `virtualenv`s (or to the system Python 3 for commands which cannot run in the `virtualenv`s, namely `bootstrap` and `create-mach-environment`).
4. Remove the "add global argument" feature from `mach`. It isn't used and conflicts with (3).
5. Remove the `--print-command` feature from `mach` which is obsoleted by these changes.
This has the effect of allowing us to install packages that cannot be vendored into a "common" place (namely the global `~/.mozbuild` `virtualenv`s) and use those from the build without requiring us to hit the network. Miscellaneous implementation notes:
1. We allow users to force running `mach` with the system Python if they like. For now it doesn't make any sense to require 100% of people to create these `virtualenv`s when they're allowed to continue on with the old behavior if they like. We also skip this in CI.
2. We needed to duplicate the global-argument logic into the `mach` script to allow for the dispatch behavior. This is something we avoided with the Python 2 -> Python 3 migration with the `--print-command` feature, justifying its use by saying it was only temporarily required until all `mach` commands were running with Python 3. With this change, we'll need to be able to determine the `mach` command from the shell script for the forseeable future, and committing to this forever with the cost that `--print-command` incurs (namely `mach` startup time, an additional .4s on my machine) didn't seem worth it to me. It's not a ton of duplicated code.
Differential Revision: https://phabricator.services.mozilla.com/D85916
There must be no pending exceptions on the JSContext when returning from a
native promise handler. We were not successfully clearing exceptions in all
cases in JSActor logic, meaning that query replies with unserializable data
would cause debug-mode crashes.
This patch handles JSActor's code, but doesn't improve the situation for other
native promise handlers which could throw exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D87110
This resolves a long-standing issue in development where `mach artifact` (and therefore `mach bootstrap`) would fail unpredictably if you had dirty, but ignored, files in your checkout. Resolving this problem often required unwieldy `hg purge`/`git ignore` incantations that are easy to get wrong.
This patch addresses the problem by doing what we "should" have been doing all along, and consulting the VCS to list tracked files rather than listing EVERY file on disk and applying heuristics to determine whether they should be included in the hash.
Differential Revision: https://phabricator.services.mozilla.com/D86780
Given that temps never alias inputs as established in the previous patch, this
assertion isn't necessary. It's possible the LSRA allocator did things differently.
The assertion was also weird/wrong because it depends on LDefinition::Type, but
there are multiple Types that could still map to the same Register. It looks
like bug 1067610 broke this; before that refactoring we compared isFloatReg().
Differential Revision: https://phabricator.services.mozilla.com/D87264
Temps cover both the input and output part of the instruction, so their ranges
always overlap with at-start uses (covering the input) and non-at-start uses
(covering both input and output). This means the allocated register must be
different from any uses.
Defs cover only the output part of the instruction so there at-start makes a
difference.
Differential Revision: https://phabricator.services.mozilla.com/D87263
I noticed this while looking at D87232. Using an exhaustive switch makes it easier to find all the places that need to be updated when adding a new ValueType.
Differential Revision: https://phabricator.services.mozilla.com/D87273
In `getMappedExpression`, we check if the expression contains `await `, and in
such case, transform the input to handle top-level await expressions.
The catch is that we first check the existence of this.parserService, and the
getter for parserService will start the parser worker if it wasn't the case yet.
That means we were always spawning the parser worker, even if it wasn't going
to be used, consuming unnecessary resources.
This patch removes the conditions in the if, as `parserService` will always be truthy.
Differential Revision: https://phabricator.services.mozilla.com/D86826
This removes the testing function and adjusts the tests that use it.
One test is removed because wasm, and asm.js, are not available
without floating point support (guarded against in HasSupport).
The patch also documents the meaning and logic of the remaining
hardware flag management.
There is already a command line switch for setting the ARM flags (and
an environment variable) so we don't need to introduce anything to
allow flags to be set. However, this code needed to be updated to
properly compute the JIT flags after setting the ARM flags.
Test cases are introduced to test that wasm is not available in
situations where the required hardware is not in place.
A final adjustment is made to HasSupport: It can call
JitSupportsAtomics() rather than test the ARM flags directly, since
the jit tests those flags on ARM.
Differential Revision: https://phabricator.services.mozilla.com/D87262
The assertion crash found by fuzzing is fixed after moving useraction state from
BrowsingContext to WindowContext, see bug 1611961.
Differential Revision: https://phabricator.services.mozilla.com/D85752
When <object> targets to a svg image, we use nsSubDocumentFrame. The
intrinsic ratio should be overridden by aspect-ratio while computing
its size on this frame.
This update in nsSubDocumentFrame also works in iframe.
Differential Revision: https://phabricator.services.mozilla.com/D79362
This includes a update of the ini file. I noticed the color
of the video is not equal to "rgb(0, 128, 0)" (i.e. background-color: green).
It is "rgb(1, 128. 1)" on Mac (without WebRender),
"rgb(0, 125, 0)" on Mac (with WebRender), and "rgb(1, 128, 2)" on Linux.
Perhaps it is a bug of our video rendering or video scaling. Therefore,
I added fuzzy into the ini file with max 0-3 difference per channel.
(Note: The size of this video is 50x50, so the max number of pixels is 2500.)
Differential Revision: https://phabricator.services.mozilla.com/D79337
Andrew Halberstadt
Miko Mynttinen
Adam Vandolder
Henrik Skupin
Julian Descottes
Ricky Stewart
julianwels
Tom Schuster
Cristina Coroiu
Andrei Oprea
Denis Palmeiro
Nika Layzell
Jan de Mooij
Julien Cristau
Bogdan Tara
ffxbld
Christian Holler
Lee Salzman
Jonathan Kew
Nicolas Chevobbe
Lars T Hansen
Sebastian Hengst
Edgar Chen
Daisuke Akatsuka
pbz
Boris Chiou