This is enabling the PLE and PLC rules across a much larger swatch of the code
base. The PLR and PLW are additionally enabled at the warning level (introduces
~2500 new warnings).
To avoid extraneous changes in people's patches, rules at the warning level are
excluded from --fix.
Differential Revision: https://phabricator.services.mozilla.com/D172358
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
This is enabling the PLE and PLC rules across a much larger swatch of the code
base. The PLR and PLW are additionally enabled at the warning level (introduces
~2500 new warnings).
To avoid extraneous changes in people's patches, rules at the warning level are
excluded from --fix.
Differential Revision: https://phabricator.services.mozilla.com/D172358
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
In some cases, TARGET_CC/TARGET_CXX are ignored by build scripts.
For consistency, also use TARGET_CFLAGS/TARGET_CXXFLAGS for Linux.
Differential Revision: https://phabricator.services.mozilla.com/D172646
Vendor in WebGPU CTS so that we can run it against our implementation of WebGPU. This patch includes:
1. Some linting configuration tweaks, to silence issues that weren't straightforward to fix in CTS upstream.
2. Some WPT runner configuration to enable preferences, and skip MacOS testing altogether (since it's not targeted by our current work).
3. A new Rust binary crate that, when run from a development environment:
1. Creates a vendored copy of WebGPU CTS in `<gecko>/dom/webgpu/tests/cts/checkout/`.
2. Generates private Web Platform Tests (see also `<gecko>/testing/web-platform/docs/index.rst`). To do this, we:
1. Use upstream test generation via `npm` scripts, which creates a single `cts.https.html` file with thousands of variants.
2. Chunk the `cts.https.html` file into parts that Taskcluster can distribute without timing out individual jobs. IMO, this is the most likely part of these changes to need further iteration, because:
1. We currently naively divide tests by number of variant, and have made no effort to empirically prove that we're dividing execution time of chunks.
2. There is currently no stability in the distribution of tests per chunk. Test variants are essentially a flattened list of the tree structure used to organize tests. Adding a few tests that end up being placed in the middle of the list can cause the chunk with new tests _and all subsequent chunks_ to have their contents changed, which will probably cause a disproportionate number of line changes to review.:
3. Fix `script` tag(s) so they actually work with the WPT test runner for private tests (viz., in the `testing/web-platform/mozilla` directory).
The output of the new vendoring binary is designed make the above steps transparent. N.B. that no actual vendoring in of files has happened yet; the next patch will add the results of running this script.
Differential Revision: https://phabricator.services.mozilla.com/D169951
The hazard analysis needs to be able to pass a parameter of type AutoCheckCannotGC&& that can be considered to be "consumed" either explicitly by calling reset() on it, or given over to a calle with std::move().
Differential Revision: https://phabricator.services.mozilla.com/D170142
This is mostly just switching the upstream tasks with pull the Windows installers from. The only wrinkle is that we're not attributing the asan-reporter installers (and we shouldn't IMO), so I had to add support for keying upstream tasks on platform in the beetmover manifests. (If we simply listed all three possible upstreams, we ended up pulling _two_ installers for platforms that are attributed...and I don't even know which one would get published, or if both would.)
Differential Revision: https://phabricator.services.mozilla.com/D170246
The kind is more or less the same as the en-US counterpart in the previous revision.
As with the en-US attribution kind, this also does does _not_ use the `multi_dep` loader to set up the per-locale tasks. Of course, we do need to split by locale, which is now being done quite explicitly by the new `split_by_locale` that looks at the specified locales file, and uses specific platforms specified in the kind. As with the previous revision, please feel free to push back if any of you feel any of this is going in the wrong direction, is worse than multi_dep, etc. etc.
Differential Revision: https://phabricator.services.mozilla.com/D170245
Notably, the actual attribution code we're using is stored in `browser`. This was largely motivated by the fact that the subsequent revision in this stack will also need it, and this seemed like the best way to make it shareable between the two. The only alternative I could come up with was stuffing it into a transforms - but it's really just data - there's no reason it ought to live in such a place. (We do have precedent for this sort of thing with both locale and whats new page information, so I don't think it's breaking huge new ground.) Nick - I'm tagging you mainly on this part, but I welcome any other comments you may have (here or in the rest of the stack for that matter).
The other notable part of this patch is that I've _explicitly_ decided not to use the `multi_dep` loader, nor reimplement any of its magic pulling of properties in a transform. I find that this makes it more clear what's _actually_ going on, and easier to debug when making changes. The dwonside, of course, is that there's some verboseness in the kind - all platforms we need to run this for must be explicitly listed. I'm open to debate on whether or not this is the right trade-off, so feel free to push back if you disagree.
Differential Revision: https://phabricator.services.mozilla.com/D170243
There's actually nothing partner-specific in this script, and it's about to be used for other types of attribution as well.
Differential Revision: https://phabricator.services.mozilla.com/D170239
The only difference with `SM(wasi)` is that this doesn't use `--without-intl-api`.
The resulting Wasm file is almost 3x larger because of this.
Maybe this could replace the non-intl build at some point, but considering the large
size difference it still seems useful to keep both for now.
Differential Revision: https://phabricator.services.mozilla.com/D172113
- For OpenSUSE Leap `python39-curses` has to be explicitly installed for Python 3.9
- For OpenSUSE Python 3.9 the `pip` binary is named `pip3.9`, so we must symlink it to `pip3` for the various Mach commands that expect it to be called `pip3`.
Differential Revision: https://phabricator.services.mozilla.com/D171934
