Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This commit merges the TypedObject namespace into the WebAssembly namespace, and
only exposes the TypedObject definitions when the GC feature is enabled.
A future commit will remove the TypedObject definitions from the namespace, but we
still need the infrastructure from this commit for storing the TypedObject definitions
in private slots in the namespace.
Differential Revision: https://phabricator.services.mozilla.com/D92857
This commit merges the TypedObject namespace into the WebAssembly namespace, and
only exposes the TypedObject definitions when the GC feature is enabled.
A future commit will remove the TypedObject definitions from the namespace, but we
still need the infrastructure from this commit for storing the TypedObject definitions
in private slots in the namespace.
Differential Revision: https://phabricator.services.mozilla.com/D92857
Now that we don't recurse into the js python configure, we don't need to
have a special treatment for the options that need to be passed down to
that subconfigure, which is what js_option was for.
Differential Revision: https://phabricator.services.mozilla.com/D92727
It was only meant to be used internally, when the top-level python
configure invoked the js python subconfigure. Now that this doesn't
happen, we can remove the option, and consolidate js_standalone and
building_js, which are now roughly synonyms.
Differential Revision: https://phabricator.services.mozilla.com/D92726
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
This gets rid of an ad-hoc boolean constant and introduces a configuration flag
for experimental SIMD instructions. The flag is on by default in Nightly if
SIMD is also enabled; otherwise off. This patch therefore disables support for
experimental SIMD instructions in beta and release, where they have been
available with the other SIMD instructions behind a pref. This seems OK:
code using unstable bits of an in-progress proposal should stick to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D92554
These two platforms are the only ones where Cranelift has a functioning
backend. It doesn't make sense to include Cranelift in the build
otherwise, and doing so may cause other issues or breakage.
Differential Revision: https://phabricator.services.mozilla.com/D92284
This lays the groundwork for ARM64 simd in the baseline compiler and
runtime. Mostly this is non-dramatic.
The main problem to be solved is SIMD register allocation and
save/restore in the stubs. We can't use the register sets in the
usual way to do this for reasons that are explained at length in
comments in Architecture-arm64.h, WasmStubs.cpp, and
WasmBaselineCompile.cpp, so there are a couple of cheats, that
basically come down to (sometimes contextually) treating doubles as
vectors. By and large this is surprisingly clean.
The patch also splits a huge test file (simd/spec/nan-flavors.js) into
many smaller files so as to avoid OOM conditions when testing on
device with --ion-eager and similar switch settings that cause massive
amounts of jit code to be allocated.
Differential Revision: https://phabricator.services.mozilla.com/D90740
We've decided to mitigate risk somewhat, for now, by enabling
Cranelift/aarch64-based Wasm support only on Nightly builds. This patch
removes Cranelift entirely from the default beta and release build
configurations. We'll plan to revisit this once we have more experience
with Cranelift on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D91960
This commit adds the boilerplate machinery for the function-references proposal. The
interesting piece is that the GC proposal is moved to require the function-references
proposal to be enabled.
The configuration machinery for features is refactored in this commit to avoid passing
6 different booleans around as parameters to functions.
* A FeatureArgs struct is added with values for all 'feature' configuration options
- A feature is defined as an option that affects validation or semantics
- Essentially everything besides 'debug', 'mode', 'tier'
* All feature configuration responsibility is removed from CompilerEnvironment
* ModuleEnvironment is modified to accept a FeatureArgs in addition to a
CompilerEnvironment
- The CompilerEnvironment field may eventually be removed, as it's not needed
within function validation, and is only used by the compilers later
Differential Revision: https://phabricator.services.mozilla.com/D89857
This adds a 'minimum' argument to the JS-API for the WebAssembly.Memory
and WebAssembly.Table objects. This parameter represents the minimum
size of the object which was specified by the 'initial' parameter. This
supports using either initial or minimum to specify the parameter.
This commit is part of the work to add type reflections to the
WebAssembly JS-API as specified in the js-types proposal.
Differential Revision: https://phabricator.services.mozilla.com/D85887
This adds a 'minimum' argument to the JS-API for the WebAssembly.Memory
and WebAssembly.Table objects. This parameter represents the minimum
size of the object which was specified by the 'initial' parameter. This
supports using either initial or minimum to specify the parameter.
This commit is part of the work to add type reflections to the
WebAssembly JS-API as specified in the js-types proposal.
Differential Revision: https://phabricator.services.mozilla.com/D85887
This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
All the supported compilers support a GNU AS-like syntax, with only a
few details varying. It means we can use a single, simpler, way to
include the ICU data file, instead of 3 different ways, including one
that uses armasm64.exe, possibly wrapped with Wine.
Differential Revision: https://phabricator.services.mozilla.com/D82144
This commit enable reference-types by default. The existing config/ifdef'ery is
spared to allow for an easier backout and to support Cranelift until it gains
support for the feature.
Depends on D81012
Differential Revision: https://phabricator.services.mozilla.com/D81013
This commit enables the bulk-memory-operations feature by default. The config/
ifdef'ery is spared to allow for easier backouts if needed.
Differential Revision: https://phabricator.services.mozilla.com/D81012
This patch generalizes the x64 code that was moved into x86-shared
code in the previous patch, and makes it all work for x86.
Generally the changes are pedestrian. The most interesting bit is
that signed right shift i64x2 is now scalarized in the compilers, not
in the macroassemblers, as this simplifies code everywhere. This
gives rise to a new kind of porting API that reveals information about
what the macroassembler supports on the platform, in the form of the
MustScalarize/MustMaskShiftCount predicates in MacroAssembler.h.
Multiply i64x2, which is scalarized in the macroassemblers now, could
have been subjected to the same treatment, but I did not do so (yet)
because this op presented fewer problems than the right shift. (Discuss.)
Differential Revision: https://phabricator.services.mozilla.com/D74935
I kept a running list of code that would be dead once we removed the old engine. This is what was on that list.
Note: The regexp_parse tests used a testing function that parsed a regexp and returned an AST to compare against the expected AST. They are being deleted because the tests are fragile in the face of upstream changes, not particularly useful, and a lot of work to convert.
Depends on D77727
Differential Revision: https://phabricator.services.mozilla.com/D77728
Currently our wasm-gc prototypes requires that typed objects are enabled,
and of course it is also dependent on reference types. So make sure the
default is computed correctly and die during configure if wasm-gc is
requested while the other options are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D77780
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Ricky Stewart
Bogdan Tara
Dorel Luca
Ryan Hunt
Razvan Maries
Mike Hommey
Lars T Hansen
Chris Fallin
Benjamin Bouvier
Jessica Tallon
Csoregi Natalia
Kannan Vijayan
Cosmin Sabou
Butkovits Atila
Ted Campbell
Iain Ireland