For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
Having Rust dump a stack on panic seems like a useful on-by-default
feature.
MozReview-Commit-ID: ABYTArsMTFh
--HG--
extra : rebase_source : 7d15f44a9ffd14db475db9e5c2964aca31bf0f70
This allows subcommands to use external argument parsers.
MozReview-Commit-ID: 7TkbTff0Tv8
--HG--
extra : rebase_source : a1c245efa7ac7b28b974534b4cd2727c96f9219d
After this patch, the following will all display the subcommand help where they previously displayed
the command help:
$ mach help <command> <subcommand>
$ mach <command> --help <subcommand>
$ mach <command> <subcommand> --help
The command help will still be shown for:
$ mach help <command>
$ mach <command> --help
MozReview-Commit-ID: 7EsVblnCaFM
--HG--
extra : rebase_source : 2a1d289d56164366ce140fa653adec93f56be067
There's no need to install the caskroom bits for Homebrew now,
allowing to fix Java installation on Mac OS X and simplify the code at
the same time.
MozReview-Commit-ID: 1Ssjm4YRrPQ
--HG--
extra : rebase_source : 3414d1fbe2bdb693cae1f5b1379d8d9335f1e7f4
This is the real fix. Google has replaced the |android --no-ui ...|
tool with a simpler |sdkmanager| tool, which makes it easier to
install packages with particular major versions. (Minor versions
still can't be controlled; for example, the m2repository extras are
constantly rolling forward.)
|sdkmanager| fails if the required packages aren't installed and can't
be installed, so there's no need to search for missing packages, etc,
simplifying the code considerably.
I don't see an easy way to upgrade outdated Android SDK installations
-- it's not clear that unpacking over top of an existing SDK
installation succeeds -- so I've included a message about moving or
removing outdated installations. This will punish folks who have
added additional Android platforms, or download emulator images using
the Android toolchain (but not those downloaded using |mach
emulator|). C'est la vie.
MozReview-Commit-ID: GLhKyuq701k
--HG--
extra : rebase_source : 26578c5ef4dcc6a29809630add2232a98407ec54
This refactoring unifies similar code that has been copy-pasted and
subsequently diverged.
MozReview-Commit-ID: EuVQBR4gsDo
--HG--
extra : rebase_source : bda66ef9001a1cddf75417aaeebd9dcecd05a6b7
This patch changes the name of the keys that are in the 'linked-files-map.json' that is produced in the code coverage build and are used to map symbolic links to their source files. The new key names (which are the paths to the symbolic links) are now the entire absolute path to each of the files.
MozReview-Commit-ID: 4x1dfk9h2Ov
--HG--
extra : rebase_source : 7d424bbbf1d026ea67c66b743c8c43ea75185733
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
The rigid type comparison added in 51a92a22d6d1 (bug 1375231) was
too rigid. This broke at least one consumer that was comparing an
empty PositiveOptionValue/NegativeOptionValue against a string.
Since comparisons against empty OptionValue are convenient and
don't violate the spirit of the type checking previously added,
this commit relaxes the type equivalence check in cases where the
OptionValue is empty.
MozReview-Commit-ID: UllTrzCjj
--HG--
extra : rebase_source : 2c41428d1be667edecdab0947d006a1a6a533569
OptionValue and its derived classes are exposed to moz.configure
files. As the previous bug fix showed, it is really easy to
accidentally assume the type is a simple string value and do a
string compare against it.
To prevent this class of bugs, this commit adds additional type
awareness to OptionValue.__eq__.
We first check that the argument is a tuple (including any OptionValue
types). If not, we raise a TypeError because the comparison is
invalid. This is arguably a violation of __eq__. But since OptionValue
is exposed to the moz.configure sandbox and typing '==' will invoke
__eq__, we have to do something to prevent this foot gun.
The change also changes the comparison logic.
If we compare against a non-derived tuple instance, we do a tuple
compare. Otherwise, we fall back to the previous logic of
requiring an identical type then doing a tuple compare.
MozReview-Commit-ID: 7IVSL2Asg9j
--HG--
extra : rebase_source : edab573834da240df9ad7c2fc78c85d6159a6ef9
Leaving off this argument makes `mach vendor rust` with large files fall
over with a Python error. While the user still gets a semi-useful error
message prior to this failing, it would be better to not fail here at all.
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
We have a flag set on all Linkables, cxx_link, denoting whether there's
anything being linked into them that requires C++. We do this even when
we link against shared libraries that required C++. But if these
libraries don't export C++ interfaces, there's no reason that the things
linking against them should require C++. Therefore, ignore shared
libraries when making the determination of whether an object requires
C++ or not.
This patch renames the mozinfo flag 'coverage' to 'ccov' to avoid ambiguity in whether a test is being skipped for linux64-ccov or for linux64-jsdcov. It also removes the 'runtests.py' mozinfo hack and renames all occurrences of 'coverage' that are used for skipping tests in linux64-ccov.
MozReview-Commit-ID: IF2640bDQP7
--HG--
extra : rebase_source : 614020325e30d1ca9e01aaf08479b8a4ffaec888
With configure now being able to auto-detect the presence of a `mach
bootstrap`-installed clang and libclang and the upcoming
build-by-defaultness of Stylo, we can start downloading these packages
all the time.
LLVM/clang is needed for Stylo's bindgen, and Apple's clang is unusable
for such purposes. For other platforms, we have installed LLVM/clang
from our tooltool archive on the supposition that those packages are
definitely known to work, as we use said packages in automation. For
Mac, however, we haven't been able to generate packages for tooltool
that successfully build Stylo, and even if we had, those packages would
solely be used for developer builds of Stylo and would not be used in
automation. The case for downloading LLVM/clang for Mac from tooltool,
therefore, is not as strong as for other platforms.
As a result, we'll rely on the installed package manager for LLVM/clang,
which many people may have installed anyway.
In passing, also delete some old code for OS X versions < 10.7; such
platforms are no longer supported for running or building Firefox.
This patch adds a flag to the 'mozinfo.json' that can be used to disable tests when they are running on linux64-ccov. Then, this flag is used to prevent the marionnette test 'test_crash.py' from running on linux64-ccov.
MozReview-Commit-ID: 9IHMiZHxcMK
--HG--
extra : rebase_source : ec690cb3ffa27d3e88d2c0b8c5d510e72a5c5079
When determining the path of a possible mozilla-central checkout,
bootstrap currently considers the existence of a `.git` directory as
sufficient proof that the containing directory is a git checkout.
Unfortunately, if you happen to execute standalone bootstrap from a git
checkout of something else, you're gonna have a bad time.
To prevent this, check for the existence of a moz.configure file. This
is not an ideal proof, but it is better than what we currently have.
The -fsanitize=integer analysis from UBSan can be helpful to detect signed and unsigned integer overflows in the codebase. Unfortunately, those occur very frequently, making it impossible to test anything with it without the use of a huge blacklist. This patch includes a blacklist that is broad enough to silence everything that would drain performance too much. But even with this blacklist, neither tests nor fuzzing is "clean". We can however in the future combine this with static analysis to limit ourselves to interesting places to look at, or improve the dynamic analysis to omit typical benign overflows.
It also adds another attribute that can be used on functions. It is not used right now because it was initially easier to add things to the compile-time blacklist to get started.
Finally, it includes a runtime suppression list and patches various parts in the test harnesses to support that. It is currently empty and it should not be used on frequent overflows because it is expensive. However, it has the advantage that it can be used to differentiate between signed and unsigned overflows while the compile-time blacklist cannot do that. So it can be used to e.g. silence unsigned integer overflows on a file or function while still reporting signed issues. We can also use this suppression list for any other UBSan related suppressions, should we ever want to use other features from that sanitizer.
MozReview-Commit-ID: C5ofhfJdpCS
--HG--
extra : rebase_source : 952043a441b41b2f58ec4abc51ac15fa71fc142f
Support OSX Signed nightlies (in the complete.mar too)
MozReview-Commit-ID: HXiFGE14wYJ
--HG--
extra : rebase_source : 1d02b4714c8fafe6cdcd74e6d9b5612c44dcb3b4
- Set the extensions.legacy.enabled pref for mochitests etc
- Skip a plugin-inside-xpi test for now if legacy extensions
are force-disabled. That test can just be removed once we
get to 57.
MozReview-Commit-ID: As9LtkQTcTS
--HG--
extra : rebase_source : fcc84daef95c453e893cc3b98498fdb87f54b1bb