When vendoring third-party files, we'd like an explicit notice/review
when said files contain a "large file". This commit adds such checks
for files vendored via `mach vendor rust`.
As we don't yet have a server-side hook in place to prevent large files
from being added, we just have a command-line flag that people are
expected to use, on the honor system, to permit large files to be added
when vendoring.
This command is useful for users who wish to perform something like the
following:
1. Add/remove a bunch of files;
2. Examine the additions/removals/modifications for interesting changes;
3. Reject the add/remove if it doesn't meet some set of conditions.
Bump the minimum version of the rust toolchain we require to
build. The 1.15 release includes support for custom #[derive]
directives, letting us use the serde serialization crate without
checking in a lot of generated code.
This is primarily motivated by webrender and the audio remoting
work, and lets us drop the heavy syntex dependency.
MozReview-Commit-ID: 6IObHhouPAn
--HG--
extra : rebase_source : 4be8b148fb653a48f6df4309811ab1d8755f7edf
Without this, clang-tidy cannot check any diffs including such files.
In the future, when checking the entire tree using clang-tidy, we will
ignore these entries in the compilation database.
The way directory traversal is computed relies on the
RecursiveMakeTraversal class, which is used to reproduce the old
traversal order from the old entirely-in-make traversal with DIRS,
PARALLEL_DIRS, etc. because of the undeclared intra-directory
dependencies that are looming here and there.
It's fed through DirectoryTraversal objects emitted by the frontend.
Normally, DirectoryTraversal objects are emitted for a directory,
possibly giving the subdirectories defined in DIRS/TEST_DIRS its
moz.build. But in the case of gyp processing, nothing places the gyp
objdirs in some virtual DIRS of some parent moz.build since bug 1308982.
As a consequence, the corresponding entries in the
RecursiveMakeTraversal instance attached to the backend are not attached
to any parent directory. When subsequently traversing the tree from the
root, they are never found, and end up being skipped, irregarding of
their actual _no_skip status.
It would probably be possible to revert the changes from bug 1308992,
but we might as well not rely on remains from the old ways. So instead,
we make the RecursiveMakeTraversal consider directories without a
declared parent attached directly to the root directory. They don't need
to depend on any other directory anyways.
--HG--
extra : rebase_source : 17403922322a71d490fdea8db0ff16b04983ed7a
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
We had been installing them to dist/plugins with the rest of the test plugins,
but tests are actually expecting them to be in dist/bin.
MozReview-Commit-ID: 9qYFgZA4Fni
--HG--
extra : rebase_source : 52a4cbf70ffe7998cfe81ab5e508b9f802dd3a35
Remove the option to build without rust code. We are not testing
this configuration and expect to land non-optional rust code in
the near future, so it doesn't make sense to maintain this option.
MozReview-Commit-ID: CwTlMXGvr5n
--HG--
extra : rebase_source : 080a9df5b4828c66aa2452ad1c16a503bcd5e689
This updates the client artifact code to locate test support files in the
common test archive and populate the objdir with these files appropriately.
MozReview-Commit-ID: GuXjwUtsl
--HG--
extra : rebase_source : 3560efee22533f60be1e7394fa0841005991cca6
Generated support files for specific tests generally end up in a harness specific
test archive, but artifact builds, which might not want to generate these files
themselves, get all of their test related files from the common.tests.zip. This
effectively moves a small number of these support files from harness specific
archives to the common test archive, making it possible to run tests that
depend on these files against artifact builds.
MozReview-Commit-ID: BvEj1ot1OTw
--HG--
extra : rebase_source : 06e958adc7b5667c50ca5ddbf06c1bf878d75737
Install manifests influence test packaging, allowing artifact builds to consume
generated test support files and run tests that depend on them. This commit
tracks binaries with an install target under "_tests" so they will be correctly
installed in artifact builds.
This could similarly be achieved by installing the binaries via TEST_HARNESS_FILES
rather than setting FINAL_TARGET, however, PGO builds will fail attempting to install
the files during the profile generation step, because SIMPLE_PROGRAMS are not built
for this step.
MozReview-Commit-ID: ES4bTxOoqMN
--HG--
extra : rebase_source : f41d8c47711fc15247fa336e2e9cbdedf57c2daf
Back when the class was written, for the packaging code, it made sense
that the default was True. But now that it's used all over the place,
and that the vast majority of uses are with find_executables=False, it
makes more sense for that to be the default.
--HG--
extra : rebase_source : ff813735fc0d53093f348f20eb77ee03e9b09d4e
And make it an error not to give it. While the default is True, we do
pass a value of False wherever it makes sense, which happens to be, in
most places.
This is an intermediate step to flip the default from True to False,
ensuring that we don't unwantedly switch some calls to False.
--HG--
extra : rebase_source : 432e03f032fef378af482581685583262e5d2661
We want to avoid giving --help dependencies to host and target, so that
they we don't spawn config.guess and config.sub when running configure
--help, and don't need to reach out to the which module to find a
suitable shell to execute them.
So, when --help is given, we return a fake host/target namespace, and
avoid the config.guess/config.sub-invoking code being executed.
Then, by giving the --help option to the linter, it can properly find
that the config.guess/config.sub-invoking code doesn't need the
dependency on --help.
This effectively unbreaks configure --help after bug 1313306.
--HG--
extra : rebase_source : 9ed4cbe5a81121b139d0d86aff6af542c2dff53b
Ideally, it would have been better if it were "or", but it's not
possible to override "or" in python ; __or__ is for "|".
This does feel magic, but it's also shorter than adding something like
@depends_any(), and while we're only adding "|" as of this change, we
can add other operations such as "&" in the future, or __getattr__ for
things like milestone.is_nightly.
An alternative form in moz.configure could require the @depends function
to be called, e.g. "a() | b()" instead of "a | b", but I'm not
particularly convinced that one is less magic than the other.
This feature is hooked up such that b is not resolved if a is true,
although in practice, it will still be resolved in Sandbox.run... but
not when --help is passed. In the long run, the forced resolution of
@depends functions will be removed from Sandbox.run.
--HG--
extra : rebase_source : 2389153acfbc3930786d5495ba4a04640325613e
Adding those dependencies, retrospectively, only worked around the poor
handling of --help requirements by the linter, that we fixed a few
commits ago. This is now not necessary anymore.
--HG--
extra : rebase_source : 0ba95ab2d246315be097fed7897db1c20666060a
Several things were wrong with the wrapping:
- the equality test on functions was actually comparing the memoized
functions, which have a type memoize, which inherits from dict. So
they weren't comparing actual functions, but the dict used to store
the cache of their invocation.
- each CombinedDependsFunction created for the same combination function
used a different wrapped function, so even if the dict problem wasn't
there, the equality test still wouldn't work, except if the function
wrapping itself was memoized.
- the memoization was not particularly useful.
Also, for upcoming changes, we'd actually like the combination function to
take an iterable instead of a variable argument list, so that items of
the iterable can be skipped.
--HG--
extra : rebase_source : 2c91889315b49695a2e2b709a9264de9ff237598
We're going to change the function signature for CombinedDependsFunction,
so make it visible in the API that the function member is not meant to
be used directly. The linter still does, though, because it needs to
look in their guts.
At the same time, avoid setting DependsFunction names via the function
name itself, because in upcoming changes, it will not be modifiable in
some cases.
--HG--
extra : rebase_source : a46ec8d3d2e2511dbb44a48cf2c02ab7ad190510
Options with a `when` argument (either directly, or inherited through
only_when() or an include) require --help per _value_for_option, but
that code path is not exercised during a lint pass.
With this change, along the previous one, we now correctly detect that
bug 1316957 was not supposed to work as is.
--HG--
extra : rebase_source : 0961c132bb200a90814b948aff7d2e80a1b21a30
Bug 1313306 relaxed the --help dependency requirement in some cases, but
while doing so, the requirement was also removed in other, unexpected
cases. Specifically, the --help dependency ended up not being required
on indirect dependencies that should have had it, had the --help
dependency been explicit on the direct dependency.
--HG--
extra : rebase_source : 81755988754798590482dfb297b7ddfc14ee88c7
It turns out there are shockingly few cases of manifestparser manifests that actually use the ';'
character as a comment. Because we will soon allow inline comments, deprecating the use of ';' will
ensure that values are allowed to have semicolons in them.
Even without inline comments, might as well enforce consistency across manifests.
MozReview-Commit-ID: AEPPQFdNXG0
--HG--
extra : rebase_source : 3540fa385f328bffb020c0a6debc4d2b3a90ed39
This is an educated guess in an attempt to solve a hard to reproduce intermittent. This
also makes sure the original SIGINT handler is restored after running the linters.
MozReview-Commit-ID: HRo0GRlSN5L
--HG--
extra : rebase_source : 7b8bf4b5818d741b5ab6a38c8c56f4eb53a801c8
If we have rustup installed, use it to check the available
target platforms and install 32-bit windows support if we're
on the (default 64-bit) windows platform.
This catches systems where the mozillabuild bootstrapper was
run before it installed this, so rustup is available, but the
i686 target library isn't.
MozReview-Commit-ID: 9bE2OQnmvxs
--HG--
extra : rebase_source : 0915fef85755718c5524b13b6b7d0d8b6dbe05b4
Windows devs often want to target 32-bit windows. Make this
easier by installing the target for them at mozboot time.
MozReview-Commit-ID: 6gFbFBOqMz8
--HG--
extra : rebase_source : 12933c6cb7895cef859c9022efa87c62f321219e
We need to mangle the path for both parts of the text printed
but rust_path_advice on windows. Otherwise the report of where
the rust binary was found ends up a mixed pathname even when
the suggested shell command is correct.
MozReview-Commit-ID: FDtP5HY8tJ1
--HG--
extra : rebase_source : ad3671be04751ece8966fa19267239b9f1614551
Adjust newlines so prompt and result information is easier to read.
MozReview-Commit-ID: BbJldqZ6G4
--HG--
extra : rebase_source : 50781f672c452e97c47d4ae07aa7f8b67a96ec50
Nathan Froyd
Gabriele Svelto
Ralph Giles
Wes Kocher
Ehsan Akhgari
Justin Wood
Mike Hommey
Phil Ringnalda
Chris Manchester
Michael Kaply
Benjamin Smedberg
Francesco Pischedda
Andrew Halberstadt
Boris Zbarsky
Andrzej Hunt
John Paul Adrian Glaubitz
Luke Wagner