The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
Bug 1438688 made it so that XPT information is compiled directly into
the binary instead of being shipped separately in interface
files. This means that manifests are no longer necessary for JS
components, which means the manifest check in emitter.py can be
removed.
That check is the only use of NO_JS_MANIFEST, so that can in turn be
removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D8885
--HG--
extra : moz-landing-system : lando
This addresses a related issue along the way: a build that results in running
configure would not update the value of self.config_environment (and therefore
self.substs) as seen from the build driver, so out of date values would have
been used.
The changes to Makefile.in and client.mk made exploit the assumption that by
he time anything in the Make build is running, config.status is up to date.
Users running "make" without the benefit of "mach" will need to manually run
configure when necessary in order to take this into account.
Differential Revision: https://phabricator.services.mozilla.com/D8473
--HG--
extra : moz-landing-system : lando
We were currently adding exclude paths to the "discard" set if the path contains
the include, but we weren't adding them if the include contains the path.
Depends on D5863
Differential Revision: https://phabricator.services.mozilla.com/D8845
--HG--
extra : moz-landing-system : lando
Right now there are excludes defined in the linter definition (via the .yml
files), as well as excludes defined in lintargs (via the mach_commands.py).
This is a minor simplification that extends each linter definition's local
excludes with the global ones right off the bat. This just makes it a bit
easier to keep track of.
Depends on D5863
Differential Revision: https://phabricator.services.mozilla.com/D8844
--HG--
extra : moz-landing-system : lando
Currently pathutils.filterpaths computes some extra paths that the underlying linter
should try to exclude if it can. It sets these on lintargs['exclude'], and relies on
the fact that it was passed by reference to work.
However, it seems like pytest does some magic under the hood that prevents this value
from being propagated back. It will also fail if 'filterpaths' was invoked in a
subprocess.
It's much simpler and cleaner to pass this value back directly, rather than rely on a
reference.
Differential Revision: https://phabricator.services.mozilla.com/D8850
--HG--
extra : moz-landing-system : lando
This fixes a latent bug that is currently not being hit (by sheer luck). Basically
the 'ignore' argument of a FileFinder object needs all paths to be relative to the
base. As luck would have it, most of the time it worked out that way if you were
running |mach lint| from the root of the repo.
However there are edge cases where this will cause an 'exclude' directive to get
missed. Plus this bug is about to be exposed 100% of the time in the next commit :).
Depends on D8842
Differential Revision: https://phabricator.services.mozilla.com/D8843
--HG--
extra : moz-landing-system : lando
I missed an edge case where the computed base itself was specified in the
paths input.
Differential Revision: https://phabricator.services.mozilla.com/D8842
--HG--
extra : moz-landing-system : lando
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
While we do have some uses of @depends-function comparison in some
templaces, related to host/target, we ought to be using `is` comparisons
rather than `==` anyways, so we switch those, and prevent other kinds of
comparisons being used at all.
This unveils the one noted in
https://phabricator.services.mozilla.com/D7713?id=21357#inline-30414
(and surprisingly only that one), that we remove entirely since it was
doing nothing in practice. Bug 1492305 will have to add it back in a
proper form.
Differential Revision: https://phabricator.services.mozilla.com/D8501
--HG--
extra : moz-landing-system : lando
Often we specify globs in our exclude patterns, e.g:
exclude:
- **/node_modules
- obj*
However, these globs get expanded out to *every* file that matches them. This
can sometimes be thousands or even tens of thousands of files.
We then pass these paths on to the underlying linters and tell them to
exclude them all. This causes a lot of overhead and slows down performance.
This commit implements a "collapse" function. Given a set of paths, it'll
collapse them into the smallest set of parent directories that contain the
original set, and that don't contain any extra files.
For example, given a directory structure like this:
a
-- foo.txt
-- b
-- bar.txt
-- baz.txt
-- c
-- ham.txt
-- d
-- spam.txt
Then the following will happen:
>>> collapse(['a/foo.txt', 'a/b/bar.txt', 'a/c/ham.txt', 'a/c/d/spam.txt'])
['a/foo.txt', 'b/bar.txt', 'c']
Since all files under directory 'c' are specified by the original set (both
'c/ham.txt' and 'c/d/spam.txt'), we can collapse it down to just 'c'. However
not all files under 'b' are specified (we're missing 'a/b/baz.txt'), so we
can't collapse 'b' (and by extension also can't collapse 'a').
If we had included 'a/b/baz.txt':
>>> collapse(['a/foo.txt', 'a/b/bar.txt', 'a/b/baz.txt', 'a/c/ham.txt', 'a/c/d/spam.txt'])
['a']
In both cases, the smallest set of paths that contains the original set (and
only the original set) is computed.
The collapse function has a little bit of overhead but it's not too bad.
For example collapsing all files matched by '**/node_modules' takes ~0.015s.
Collapsing two full objdirs, takes ~0.6s. But a follow up commit is planned to
make sure we stop using 'obj*' to reduce that overhead.
Depends on D7738
Differential Revision: https://phabricator.services.mozilla.com/D7739
--HG--
extra : moz-landing-system : lando
If scandir is already present on the system the attempt to import the
c helper library will currently find the c helper from the system
install which may well be an outdated verion, so causing mach to
break. To solve this this patch does two things:
* Stops importing scandir in files that are run unconditionally when
invoking mach. This is generally considered good for performance
reasons.
* Installs the vendored scandir into the virtualenv for `mach lint`
rather than trying to import it directly from the source tree and so
not getting the c helper library.
Differential Revision: https://phabricator.services.mozilla.com/D8379
--HG--
extra : moz-landing-system : lando
At least one Python package that got vendored via `mach vendor python`
contains a symlink, which hg.mozilla.org rejects. This change makes it so
symlinks get replaced with the contents of the file they point to.
Differential Revision: https://phabricator.services.mozilla.com/D4135
--HG--
extra : moz-landing-system : lando
This patch adds two new actions to virtualenv_packages.txt processing:
windows and !windows. The former processes the rest of the action only on
Windows, and the latter processes it only on non-Windows.
These new features are used in virtualenv_packages.txt to use the
path to the unpacked Windows psutil wheel when on Windows, and build psutil
from source and use that path on other platforms.
This fixes the long-standing problem of not having psutil available on most
Windows systems (since they don't have the right set of Visual C++ build tools).
Differential Revision: https://phabricator.services.mozilla.com/D3437
--HG--
extra : moz-landing-system : lando
This option is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows. To that end the mach command will error if you
try to use it for anything but vendoring a single package. The mach command
will vendor source packages as it currently does, and then run `pip download`
again with some hardcoded parameters to fetch the right wheel for Python 2.7
on win64 and unpack it to a `package-platform` directory under
`third_party/python`.
I don't expect this to be used for anything but psutil, but it should make life
simpler for anyone that wants to update our vendored copy of psutil in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D3435
--HG--
extra : moz-landing-system : lando
Often we specify globs in our exclude patterns, e.g:
exclude:
- **/node_modules
- obj*
However, these globs get expanded out to *every* file that matches them. This
can sometimes be thousands or even tens of thousands of files.
We then pass these paths on to the underlying linters and tell them to
exclude them all. This causes a lot of overhead and slows down performance.
This commit implements a "collapse" function. Given a set of paths, it'll
collapse them into the smallest set of parent directories that contain the
original set, and that don't contain any extra files.
For example, given a directory structure like this:
a
-- foo.txt
-- b
-- bar.txt
-- baz.txt
-- c
-- ham.txt
-- d
-- spam.txt
Then the following will happen:
>>> collapse(['a/foo.txt', 'a/b/bar.txt', 'a/c/ham.txt', 'a/c/d/spam.txt'])
['a/foo.txt', 'b/bar.txt', 'c']
Since all files under directory 'c' are specified by the original set (both
'c/ham.txt' and 'c/d/spam.txt'), we can collapse it down to just 'c'. However
not all files under 'b' are specified (we're missing 'a/b/baz.txt'), so we
can't collapse 'b' (and by extension also can't collapse 'a').
If we had included 'a/b/baz.txt':
>>> collapse(['a/foo.txt', 'a/b/bar.txt', 'a/b/baz.txt', 'a/c/ham.txt', 'a/c/d/spam.txt'])
['a']
In both cases, the smallest set of paths that contains the original set (and
only the original set) is computed.
The collapse function has a little bit of overhead but it's not too bad.
For example collapsing all files matched by '**/node_modules' takes ~0.015s.
Collapsing two full objdirs, takes ~0.6s. But a follow up commit is planned to
make sure we stop using 'obj*' to reduce that overhead.
Depends on D7738
Differential Revision: https://phabricator.services.mozilla.com/D7739
--HG--
extra : moz-landing-system : lando
By doing this in the packager, it makes it easier to incorporate the
strip and XZ compress logic into the local Gradle build process.
To that end, this patch makes XZ compression a little more explicit in
package-manifest.in and lifts the logic next to the existing logic for
stripping. Since we only want to XZ compress assets/ (and not libs/),
we need a new flag.
Differential Revision: https://phabricator.services.mozilla.com/D7314
--HG--
extra : moz-landing-system : lando
By doing this in the packager, it makes it easier to incorporate the
strip and XZ compress logic into the local Gradle build process.
To that end, this patch makes XZ compression a little more explicit in
package-manifest.in and lifts the logic next to the existing logic for
stripping. Since we only want to XZ compress assets/ (and not libs/),
we need a new flag.
Differential Revision: https://phabricator.services.mozilla.com/D7314
--HG--
extra : moz-landing-system : lando
In bug 1461714 we run node.py to generate main.js in the objdir, and use
FINAL_TARGET_FILES to install it into dist. However, when both rules are
run in parallel in the misc tier, the install target may pick up the
main.js file from the srcdir via VPATH, so we end up with the wrong file
in dist. This causes some mochitests to fail with "uncaught exception -
SyntaxError: import declarations may only appear at top level of a
module at
@resource://devtools/client/debugger/new/src/main.js:7:undefined"
The workaround here is to run these node.py invocations (which always
write to node.stub) in the export tier, so that when the install target
in misc is processed, the objdir version of the file is always present
and takes precedence.
A better fix would probably be to remove our reliance on VPATH, and just
pass in the path to files in the srcdir when they are required. That
could potentially be a major overhaul, however.
MozReview-Commit-ID: JZ04C7zJPbX
Differential Revision: https://phabricator.services.mozilla.com/D7770
--HG--
extra : moz-landing-system : lando
This fixes treatment of Windows paths, where tilde is not special,
particularly in short file names.
--HG--
extra : rebase_source : be1873a44cb2d3fa455e7bd4a31bb7c221f19213
The previous code split a lot of logic between the update and download
parts, and exposed two different mach commands. In order to simplify
things it's better to have a single entry point for manifest download
and update, and ensure that's called consistently.
Differential Revision: https://phabricator.services.mozilla.com/D7497
This is a fairly straightforward port of the AS tool checks from old-configure
to toolchain.configure. AS is a little quirky in that we currently do a
normal-looking check for it, but then override that value to be the C compiler
for non-Windows builds, and ml[64]/armasm64 for Windows builds.
After migrating those checks, the only things left in the MOZ_DEFAULT_COMPILER
macro in compiler-opts.m4 were some unused bits, so I removed them:
* Setting of CPP/CXXCPP, which are set in toolchain.configure now
* Setting HOST_LDFLAGS to empty, which doesn't seem particularly useful.
There was also a quirky old test that the assembler was ml[64] when js-ctypes
is enabled that I removed, I don't think it provides any value since this
patch will ensure that we're using the right assembler for Windows builds.
Behavior changes:
- instead of reading the mozconfig file, it now instantiates an instance of the build object.
- safe checking methods are used to access attributes to prevent errors on automation environment.
- better mach command parsing is performed with handler category instead of error-prone argv parsing.
Other changes:
- docstring for testing/xpcshell/runxpcshelltests.py::buildTestList() added and modernized.
- added clause that if length of tests gathered is 0, mach exits with an error code of 1.
Differential Revision: https://phabricator.services.mozilla.com/D7133
--HG--
extra : moz-landing-system : lando
The previous code split a lot of logic between the update and download
parts, and exposed two different mach commands. In order to simplify
things it's better to have a single entry point for manifest download
and update, and ensure that's called consistently.
Differential Revision: https://phabricator.services.mozilla.com/D7497
--HG--
extra : moz-landing-system : lando
blessings.tigetstr is not part of its API. It happens to work because
blessings imports curses using 'from curses import tigetstr'.
Instead, we can just use terminal.normal, which contains the string we were
going to get anyway.
See https://github.com/erikrose/blessings/pull/138 for more information.
Let me know if there's a better way of resolving this. Hopefully with this +
the patch I submitted to blessings (https://github.com/erikrose/blessings/pull/137)
firefox will build fine with TERM improperly set.
Differential Revision: https://phabricator.services.mozilla.com/D5377
--HG--
extra : moz-landing-system : lando
- added checkers in python/mach/mach/main.py prior to calling registrar.py.
- added internal function to check if specified debugger is installed.
- support both ./mach test <test_name> and ./mach <test_category> styles.
Differential Revision: https://phabricator.services.mozilla.com/D7234
--HG--
extra : moz-landing-system : lando
- added checkers in python/mach/mach/main.py prior to calling registrar.py.
- added internal function to check if specified debugger is installed.
- support both ./mach test <test_name> and ./mach <test_category> styles.
Differential Revision: https://phabricator.services.mozilla.com/D7234
--HG--
extra : moz-landing-system : lando
- moved placement of the raise_exception computation to be after the initial objdir path computation.
- original implementation was missing detection for cases where user may pass in a False flag to explicitly suppress errors.
- added unit tests to check for scenarios where raise_exception flag is passed in as part of positional argument.
- changed argument to include a **kwargs argument for caller to modify default exception behavior.
- default behavior is to raise exceptions if mozinfo.json cannot be found.
- disabled TreeMetadataEmitter from calling mozinfo.find_and_update_from_json and setting the self.info variable since it was not referenced anywhere else after the initial setup.
Depends on D6859
Differential Revision: https://phabricator.services.mozilla.com/D6860
--HG--
extra : moz-landing-system : lando
There is only a single linter (test-disable.yml) that uses a glob in any
include path, and that usage is easily replaced by using the 'extensions' key
instead.
Since globs in include directives aren't very useful, let's disallow them. This
will allow us to simplify the 'filterpaths' logic quite substantially and make
future refactorings in this area easier.
Differential Revision: https://phabricator.services.mozilla.com/D6798
--HG--
extra : moz-landing-system : lando
This extracts the current logic for finding nodejs into its own module in mozbuild. Configure and ESLint then use it.
For ESLint, this will change the first location it looks for nodejs to be the .mozbuild directory.
Differential Revision: https://phabricator.services.mozilla.com/D6430
--HG--
extra : moz-landing-system : lando
This makes things more explicit. Previously we were relying on those magic
global "linters" variables, and it turned out that one of the tests was
actually linting a completely different set of linters than I was expecting.
This changes things so each test needs to explicitly define which linters it
wants to use.
Depends on D6410
Differential Revision: https://phabricator.services.mozilla.com/D6412
--HG--
extra : moz-landing-system : lando
This makes this test match all the other tests (which are named after the module
they are testing).
Also rename the test function to 'test_filterpaths'.
Differential Revision: https://phabricator.services.mozilla.com/D6410
--HG--
rename : python/mozlint/test/test_filterpaths.py => python/mozlint/test/test_pathutils.py
extra : moz-landing-system : lando
This patch gets us building an updater binary that always embeds the dep certificates (instead of release or nightly), and builds a new tests package that includes it.
This was originally D5900, but that was backed out due to busting artifact builds. I've fixed that by removing the Makefile that Ted pointed out is unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D6418
--HG--
extra : moz-landing-system : lando
Migrates strings from aboutUrlClassifier.dtd and aboutUrlClassifier.properties files to aboutUrlClassifier.ftl
Modifies aboutUrlClassifier.xhtml and aboutUrlClassifier.js to use fluent.
Differential Revision: https://phabricator.services.mozilla.com/D5156
--HG--
extra : moz-landing-system : lando
Changes the wpt manifest path to the topobjdir instead so it can be moved out of tree.
Other changes so that the manifest download and update, and |mach wpt| and |mach test <wpt-test>| work with the new path.
The manifest is also downloaded and updated when creating the tests-archive to ensure that it exists when we run tests on TC.
MozReview-Commit-ID: Fp6UsKJjhTU
Differential Revision: https://phabricator.services.mozilla.com/D5312
--HG--
extra : moz-landing-system : lando
Add support for |with Files('a/**', 'b/**')| in mozbuild config files.
MozReview-Commit-ID: IoM4qfEhXXc
Differential Revision: https://phabricator.services.mozilla.com/D5315
--HG--
extra : moz-landing-system : lando
This is a quick fix to workaround linking in rkv and lmdb-sys in the tup
backend. Bug 1492291 is a followup to actually fix the problem more
generally.
MozReview-Commit-ID: 523it7WEUad
Differential Revision: https://phabricator.services.mozilla.com/D6285
--HG--
extra : moz-landing-system : lando
This patch gets us building an updater binary that always embeds the dep certificates (instead of release or nightly), and builds a new tests package that includes it.
I had a lot of trouble getting the test package generated correctly due to the fact that things in "_tests" won't be included for test packages that aren't "common". My fix for that isn't ideal - I'm open to something better.
Differential Revision: https://phabricator.services.mozilla.com/D5900
--HG--
extra : moz-landing-system : lando
Changes the wpt manifest path to the topobjdir instead so it can be moved out of tree.
Other changes so that the manifest download and update, and |mach wpt| and |mach test <wpt-test>| work with the new path.
The manifest is also downloaded and updated when creating the tests-archive to ensure that it exists when we run tests on TC.
MozReview-Commit-ID: Fp6UsKJjhTU
Differential Revision: https://phabricator.services.mozilla.com/D5312
--HG--
extra : moz-landing-system : lando
Many Windows tools don't deal well with absolute paths for filenames,
oddly enough, so we want to pass relative paths into the source
directory where possible. These relative paths also mean that they look
like "normal" unix paths to WSL and therefore don't require any special
handling.
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
Add support for |with Files('a/**', 'b/**')| in mozbuild config files.
MozReview-Commit-ID: IoM4qfEhXXc
Differential Revision: https://phabricator.services.mozilla.com/D5315
--HG--
extra : moz-landing-system : lando
This will make it easier to add new test cases in the future. It'll
also make it easier to print debug, as only the output for each
specific test case will be printed on failure.
Differential Revision: https://phabricator.services.mozilla.com/D5862
--HG--
extra : moz-landing-system : lando
This introduces two new crates:
- jsrust, for standalone builds. This crate is compiled into a static library
libjsrust.a, which gets linked into the shared Spidermonkey library when it's
built, or into the static Spidermonkey library otherwise. This is just a
static library wrapping jsrust_shared below.
- jsrust_shared, for Gecko embedding. It just references other Rust
crates actively used in Spidermonkey. It is used to be embedded as part of
a new Rust dependency in Gecko (in gkrust).
--HG--
rename : js/src/wasm/cranelift/Cargo.toml => js/src/rust/Cargo.toml
extra : rebase_source : 84e440e3f669b73776653182cb7b006cc7febb10
extra : histedit_source : 3a67575ff6871b7dc3558c10a0251b73cedb090c
Now that we ship builds using clang on all platforms, pick it during
configure. It is still possible to opt-in to building other compilers by
setting CC/CXX (or even only CC) to the desired compiler.
Depends on D5829
Differential Revision: https://phabricator.services.mozilla.com/D5637
--HG--
extra : moz-landing-system : lando
While those builds are not fully supported yet, it's better to ensure
the coming changes to toolchain.configure won't break them.
Differential Revision: https://phabricator.services.mozilla.com/D5828
--HG--
extra : moz-landing-system : lando
This will be used when we migrate away from XBL and to a Custom Element
in the following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D5598
--HG--
extra : moz-landing-system : lando
Currently, when building for Android x86-64 on Linux x86-64, we drop the
'--target' flag, which causes the build to fail. This patch adds a check
for OS mismatch, so we keep the '--target' flag in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D4483
Imports the changes to the UpdateVerifyConfig class, and sets --override-certs for staging releases.
Differential Revision: https://phabricator.services.mozilla.com/D5705
--HG--
extra : moz-landing-system : lando
This patch makes the bootstrap code "ask" Gentoo's package manager for
human-readable information on how to get the latest JDK, then parses it and
locates the tarball URL on its own. The whole procedure is now fully automatic
(until the package output or Oracle web pages change).
Differential Revision: https://phabricator.services.mozilla.com/D5544
--HG--
extra : moz-landing-system : lando
This change is necessary for constructing relative paths between the
objdir and srcdir to succeed, and has been (I believe) the implicit
requirement of builds since time immemorial.
clang can handle MSVC-like codepaths generally, so we want to use those
when building with clang for Windows. So we switch _MSC_VER over to _WIN32
to pick up those codepaths when compiling for Windows with clang.
Additionally, we relax the ordering of sections for the same scenario.
Note that we do need to tell clang to use -fms-extensions with the MSVC code,
we do that in the mingw clang build job patch.
Differential Revision: https://phabricator.services.mozilla.com/D3526
--HG--
extra : moz-landing-system : lando
We don't actually ship XPT files anymore, but it's still useful for the
packager code to handle old Firefox versions. But for that, we don't
really need the complexity of "linking" XPT files in a single unit per
directory. We can just as well keep the XPT files intact, as long as we
retain individual `interfaces` manifest entries for each.
And since those entries used to be all merged into one, we now instead
group them all together in manifests (which also happens to make it
easier on unit test changes).
Differential Revision: https://phabricator.services.mozilla.com/D5221
--HG--
extra : moz-landing-system : lando
:mreid sent a review of my pull request and informed me that the
JSON schemas used in the data pipeline are all 2-space indented.
If we want to use this script to generate any future changes to
the build system schema, we should make sure it outputs data
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D4149
--HG--
extra : moz-landing-system : lando
This patch rewrites `gather_telemetry` to collect data matching the new schema.
This includes all required fields and most of the optional fields. Some fields
are not currently recorded and followup bugs have been filed to track their
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D4598
--HG--
extra : rebase_source : 0819e8519cfcf75ba0f554c110d1815b6f71af63
We already trim the display of output lists for GENERATED_FILES scripts
that produce many outputs, so we should do the same for rust build
scripts. This makes the terminal output of the build and the nodes from
'tup graph' more readable.
MozReview-Commit-ID: AftmrA4qJlr
Differential Revision: https://phabricator.services.mozilla.com/D4797
--HG--
extra : moz-landing-system : lando
Use the unused 'p' bit in the version code to denote 64-bit builds, so
we have different version codes for 64-bit builds on aarch64 and x86-64.
Differential Revision: https://phabricator.services.mozilla.com/D4260
--HG--
extra : moz-landing-system : lando
This warning spam happens particularly with WebRTC, but I can see it
happening for any third-party software whose use of WINVER and friends
conflicts with our own. Let's just change mozilla-config.h to avoid
defining these macros if they're already defined via the command line.
Use shutil.which in mozbuild for Python 3 instead of vendored third-party package, and enable mozversion tests that are fixed under Python 3 by this change.
Differential Revision: https://phabricator.services.mozilla.com/D4184
--HG--
extra : moz-landing-system : lando
After fixing the absolute path issue in codespell, I noticed that the stylish
formatter doesn't indent lint issues that don't have a column properly. This
was never noticed before since most other linters have a column attribute.
Depends on D4012
Differential Revision: https://phabricator.services.mozilla.com/D4013
--HG--
extra : moz-landing-system : lando
Currently there are 3 things that can impact the result of a lint run:
1. The list of lint issues found
2. The set of failures that happened during the setup phase
3. The set of failures that happened during the execution phase
All three of these things are stored as instance variables on the LintRoller
object, and then passed into a formatter when it comes time to print the
results. I'd like to add even more things that can impact the result, and it
became clear that the current scenario does not scale well.
This patch moves all data that could impact the end result of a lint run off of
the LintRoller object and onto a new 'result.ResultSummary' class. To avoid
confusion, this patch also renames the 'result.ResultContainer' class to
'result.Issue'.
With this new nomenclature:
result -> overall state of an entire lint run (can comprise multiple linters)
issue -> one specific lint infraction (at either 'warning' or 'error' level)
failure -> a non-recoverable error in the linter implementation itself
A "result" is comprised of 0 or more "issues" and 0 or more "failures".
Differential Revision: https://phabricator.services.mozilla.com/D3819
--HG--
extra : moz-landing-system : lando
As of this patch, any lint issue at the "warning" level will *only* be displayed
if --warnings is passed in. This gives us some flexibility to track issues that
are "recommended to fix" but that aren't required (aka don't cause a backout).
I think it would be ideal if the reviewbot ran with warnings enabled, and CI
ran without warnings. This way these issues will be surfaced to developers
(and hopefully get fixed prior to landing), but developers will always be able
to ignore them if the situation warrants it.
Since the last change converted everything to use errors, this patch should
be a no-op for now. However as we move forward (and potentially decide that
certain types of lint issues should result in a backout), this feature will
start seeing more and more use.
Depends on D3820
Differential Revision: https://phabricator.services.mozilla.com/D3821
--HG--
extra : moz-landing-system : lando
moz.configure looks for rustc/cargo on PATH and in ~/.cargo/bin.
Bootstrap only looks on PATH and not in ~/.cargo/bin, though it is smart
enough to complain if rustc/cargo can't be found on PATH and you have
them in ~/.cargo/bin. Bootstrap should look in both places by default,
and be content if it finds them wherever they are, so long as
moz.configure can find them.
The state directory is in $HOME by default, so should be fine to just create it
if we get --no-interactive I think.
Differential Revision: https://phabricator.services.mozilla.com/D3838
By default, when the launcher process is enabled, it does not wait for the
browser process to complete before terminating. mach run expects its child
process to keep running until the browser is terminated.
If we pass -wait-for-browser to the launcher process, the launcher will not
terminate until the browser process has finished, thus preserving the existing
semantics.
--HG--
extra : amend_source : cc848f955e14d7a97c1c506247fa2788261912f2
The telemetry gathering code is currently split in two places, so move it
all to a common place. Followup patches will rewrite most of this code.
--HG--
extra : rebase_source : afd14940f7175f7ca730a3b90ad770f143bcb6c7
Daniel Varga
Andrew Halberstadt
Nick Alexander
Andrew McCreight
Chris Manchester
Dave Hunt
Dorel Luca
Tom Ritter
Cosmin Sabou
Mike Hommey
Csoregi Natalia
Narcis Beleuzu
James Graham
Andi-Bogdan Postelnicu
Qinghao_Jack_Song
Ciure Andrei
Ted Mielczarek
Noemi Erli
Mike Shal
Adam Gashlin
Tooru Fujisawa
Nathan Froyd
Edwin Gao
Raza Haider
Jay Kamat
Brindusan Cristian
shindli
Aaron Klotz
Haik Aftandilian
Paul Adenot
Dan Mosedale
Jim
Mark Banner
Bob Clary
Collin Wing
Ben Hearsum
Coroiu Cristina
Jack Smith
Ahilya Sinha
Ted Campbell
Bogdan Tara
arthur.iakab
Matt Brubeck
Masatoshi Kimura
Benjamin Bouvier
Brian Grinstead
Robert Bartlensky
Jim Chen
Chris Peterson
Gian-Carlo Pascutto
Steve Armand
Gabriele Svelto
Andreea Pavel
Robert Longson
Kartikaya Gupta
Francesco Lodolo (:flod)
Connor Sheehan
Gurzau Raul
Myk Melez
Preeti Mukherjee
Jan Henning
Tom Prince
Lifan Zeng
Bas Schouten
Panos Astithas
Emilio Cobos Álvarez