We define extra_toolchain_flags for passing extra flags to the target
compiler during configure. But the way things are currently set up, we
pass those flags to the host compiler during configure as well. This
behavior is incorrect, and we should only be passing the flags from
extra_toolchain_flags if we're compiling for the target.
We define extra_toolchain_flags for passing extra flags to the target
compiler during configure. But the way things are currently set up, we
pass those flags to the host compiler during configure as well. This
behavior is incorrect, and we should only be passing the flags from
extra_toolchain_flags if we're compiling for the target.
Various people want to start experimenting with Python 3 in the build
system and in related tools (like mach).
We want to make it easy to find and use an appropriate Python 3
binary.
This commit introduces a generic function for finding a Python 3
binary and resolving its version.
We use the new code in configure to set PYTHON3 and PYTHON3_VERSION
subst entries for later consultation.
We also expose a cached attribute on the base class used by many
mach and build system types to return a Python 3 executable's info.
By default, we only find Python 3.5+. From my experience, Python 3.5
was the first Python 3 where it was reasonable to write code that
supports both Python 2 and 3 (mainly due to the restoration of the
% operator on bytes types). We could probably support Python 3.4
in the build system. But for now I'd like to see if we can get
away with 3.5+.
MozReview-Commit-ID: BlwCJ3kkjY9
--HG--
extra : rebase_source : b00464972183ef1a97a0b5d888520be425717ae7
Bump the minimum required version of the Rust toolchain to
the current stable release so we can take advantage of new
features.
Highlights of the 1.19.0 release:
* C-compatible `union` (untagged enums).
* Support for Visual Studio 2017.
* Non-capturing closures can be coerced to `fn` bindings.
* Numeric field names in tuple struct initializers.
* Higher macro recursion limit.
* `break` can return a value from `loop` expressions.
* Better error handling with mis-configured Visual Studio environments.
This change also enables 1.18.0 features. Some highlights:
* `pub(mod)` &c. for better control of symbol visibility.
* struct packing for better memory footprint in generated code.
* Faster build times.
MozReview-Commit-ID: 2OpUjAcytpE
--HG--
extra : rebase_source : 2ed0d7c4e7b78c26f7a7476e7b284bf1bdbe7c8b
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : e53928127470340275f0c0f07db72b536bba885b
extra : source : a8373914cbfd9b8595fc24f36c876cab0a26c02a
Often you only want to evaluate a function if all its dependencies
are true. Expressing this in a "when" can be difficult. So let's
add a convenience decorator for it.
The existing code for @depends_if() was refactored to take an
evaluation function as its first argument. This prevents some
duplicate code and turns @depends_if() and @depends_all() into
one-liners.
MozReview-Commit-ID: Jbugvf0lioM
--HG--
extra : rebase_source : 177741b80ac4fbfb547d6b36a6f5777fe514d91a
extra : source : 0c2bc12f4ebe44428385745266d2fd158e0c3382
Configure now detects VCS info. Configure now detects Watchman.
We can combine the two so configure can detect if Mercurial
is configured with Watchman enabled.
This commit does two things:
1) collects the Mercurial config so it is available to downstream checks
2) examines the config for presence and state of the fsmonitor
extension
We don't yet do anything with the fsmonitor state. But it should be
useful soon. Also, the return value is kinda wonky. This will almost
certainly be improved as soon as there is an actual consumer.
MozReview-Commit-ID: HyHZ2X8VI0h
--HG--
extra : rebase_source : d245d316cc8a27b2827b7824204549b91465bd34
Often you only want to evaluate a function if all its dependencies
are true. Expressing this in a "when" can be difficult. So let's
add a convenience decorator for it.
The existing code for @depends_if() was refactored to take an
evaluation function as its first argument. This prevents some
duplicate code and turns @depends_if() and @depends_all() into
one-liners.
MozReview-Commit-ID: Jbugvf0lioM
--HG--
extra : rebase_source : 38b4af7b668830589126e8a83f5d5ab73914d07c
In bug 1181040, we added ${var}_IS_SET variables for
mk_add_options-defined variables. In the two years since, that has never
been used for anything else than MOZ_PGO_IS_SET, and the only use for
that has now been removed, so remove those ${var}_IS_SET variables.
--HG--
extra : rebase_source : 2fc9abe0c3badbf06f3858fcf326237e67891fee
Some gaia-related code was also found and removed as part of the
cleanup.
MozReview-Commit-ID: DEjVSljzzu1
--HG--
extra : rebase_source : 58c4c34df44a258d90029853f29ea01338bd142b
Bug 1365859 introduced a dependency on the Visual Studio binary 'fxc'
to generate Shader bytecode. This was unavailable when compiling for
Windows on Linux as part of a MinGW build.
This commit adds a configure check for fxc, and also searches for
fxc2, which was written (https://github.com/tomrittervg/fxc2) to be
a tiny application that wraps D3DCompileFromFile and can produce
similar (but not exactly the same) output as fxc.
fxc2 is compiled using MinGW for Windows, and runs under wine, so
we need to check for wine also.
Finally, fxc outputs some include information fxc2 doesn't, so
we will just change that assert to not take effect.
MozReview-Commit-ID: 8LVxuODi6cV
--HG--
extra : rebase_source : 9116d266663284d6594e34aa53bd37eae01ba67f
This option was added ~decade ago; AFAICT from bug archaeology, the
option was added to prevent our servers from being overwhelmed.
Somewhere over the years, however, we obtained more capable servers and
the option disappeared from mozconfigs. It seems moderately unlikely
that we'll have a need for this option again, and we could reintroduce
this patch very easily in any event. Let's go ahead and remove it.
The values that we need to find in the registry can be inconsistent across
different installations, so we retrieve values from both views in our search
for a valid SDK. This also ensures this works for 32-bit and 64-bit python.
Mercurial installs on Windows often provide both a native hg.exe
and a hg shell script. This allows them to work from both Windows
and UNIX-like shells.
While the which Python package searches for .exe and other common
executable extensions on Windows automatically, it doesn't prefer
these results to an extension-less value. This meant that "hg"
was resolved to the shell script. When we went to run it, it
failed because it isn't a valid Win32 application.
We work around the problem by preferring "hg.exe" over "hg"
for the binary name.
Ideally this would be platform specific. But the harm should be
minimal.
--HG--
extra : rebase_source : 1354c739de1ff738812ad100176ad7e9d08fadde
This is now required as of 00ef8018730c.
Landing on a CLOSED TREE.
--HG--
extra : rebase_source : 410e4a677cdc1f1238f778a00078ac6e6de420bd
extra : amend_source : e81cf510948bedd76ac77790eb96aae1fe3cda1c
For reasons unknown to me, Windows CI is periodically failing to find
the Mercurial binary.
In addition, we've also reimplemented various VCS logic throughout
the build system. There is room to cut down on code complexity by
e.g. recording VCS info in configure instead of determining it
at run-time.
Also, for forensic purposes it is sometimes desirable to know which
VCS tool is in use by a build and which version of that tool is being
used.
This commit adds VCS type detection, binary searching, and version
resolution to configure.
substs now contains VCS_CHECKOUT_TYPE, HG, and GIT, which can be
consulted by downstream consumers.
If the Mercurial or Git versions could not be resolved, all variables
are not set. Otherwise, VCS_CHECKOUT_TYPE and one of HG or GIT is set.
If MOZ_AUTOMATION is set, we require that the VCS info be resolved.
This helps prevents weirdness in automation due to unexpected
environment configuration.
MozReview-Commit-ID: AMLy0Hfx5rD
--HG--
extra : rebase_source : edef9165d32dc47308a14b0fbabce3c1d3d28176
And include code to work around a bug on older Python versions.
MozReview-Commit-ID: 4pBnMQQJOGB
--HG--
extra : rebase_source : 6f7c5784230bd37b3496b9bb1781e8d342f741b4
developer_options (!--enable-release) implies to search for and prefer
the gold linker. As part of porting gold detection to moz.configure
in d0e782180741 (bug 1351109), the logic inadvertently changed to
require gold when either --enable-gold or !--enable-release were
present.
This commit relaxes the requirement to find gold when only --enable-gold
is true.
MozReview-Commit-ID: HTBicWNUkvy
--HG--
extra : rebase_source : dd3938a7914f5db6c315fb775e7cc5ea177bf600
check_prog, when used with a `when` argument, doesn't work the same way
as putting it under a `with only_when()` block, while it should. The
difference comes from the fact that `with only_when()` applies the
`when` to every option and depends used in the block (which check_prog
calls a bunch of).
So, we "manually" apply the `when` to all option and depends in
check_prog. An alternative solution would be to put the whole function
under a `with only_when()` block, but that would mean reindenting the
whole function.
Either way, as a consequence, this requires the `when` to have a
dependency on --help for "non-trivial" functions, which fortunately,
there's only one of.
--HG--
extra : rebase_source : d91eca9e303c7062394d92a526983714ef3e612f
For reasons unknown to me, Windows CI is periodically failing to find
the Mercurial binary.
In addition, we've also reimplemented various VCS logic throughout
the build system. There is room to cut down on code complexity by
e.g. recording VCS info in configure instead of determining it
at run-time.
Also, for forensic purposes it is sometimes desirable to know which
VCS tool is in use by a build and which version of that tool is being
used.
This commit adds VCS type detection, binary searching, and version
resolution to configure.
substs now contains VCS_CHECKOUT_TYPE, HG, and GIT, which can be
consulted by downstream consumers.
If the Mercurial or Git versions could not be resolved, all variables
are not set. Otherwise, VCS_CHECKOUT_TYPE and one of HG or GIT is set.
If MOZ_AUTOMATION is set, we require that the VCS info be resolved.
This helps prevents weirdness in automation due to unexpected
environment configuration.
MozReview-Commit-ID: AMLy0Hfx5rD
--HG--
extra : rebase_source : edef9165d32dc47308a14b0fbabce3c1d3d28176
And include code to work around a bug on older Python versions.
MozReview-Commit-ID: 4pBnMQQJOGB
--HG--
extra : rebase_source : 6f7c5784230bd37b3496b9bb1781e8d342f741b4
When cross-compiling, rust-bindgen needs the -isysroot
flag we pass to the C++ compiler to find the correct
headers. Add a new BINDGEN_CFLAGS environment variable
for passing this and other relevant options, and reformat
its contents in toolchain.configure so we can use autoconf-
style template substitution to poke it into a bindgen.toml
file to be read by build scripts like build_gecko.rs.
Set this variable from the macosx/cross-mozconfig.common
to the same extra flags we pass to CXX so automation
builds work correctly with --enable-stylo.
MozReview-Commit-ID: 7wabObiFtVb
--HG--
extra : rebase_source : eeba30e3d64112da65e2e6830ef5fc1b54965529
_LIBCPP_ALWAYS_INLINE and its EXCEPT_GCC49 counterpart are broken in the
same fashion as _LIBCPP_INLINE_VISIBILITY and can be fixed in exactly
the same way.
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
This gives us source file names with repository info in our generated
symbol files, so that crash reports on crash-stats can link to the
correct source files for files from the Rust standard library.
I've hardcoded the source paths that the Rust project uses, which is
not my favorite thing, but there's no simple way to get this information
otherwise.
MozReview-Commit-ID: 6SeaMqH8xfc
--HG--
extra : rebase_source : 227a52db42b3f86378d744e68b4d88d2d8ba9757
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 : 64aa804965d24bb90b103c00c692a2ac6859e408
Chris Peterson
Nathan Froyd
Sebastian Hengst
Gregory Szorc
Matt Brubeck
Sylvestre Ledru
Ralph Giles
Nick Alexander
Carsten "Tomcat" Book
Wes Kocher
Mike Hommey
Tom Ritter
Bob Owen
Ryan VanderMeulen
Jean-Yves Avenard
Christian Holler
Ted Mielczarek