This was originally from bug 1528374 for Mac PGO, but that isn't able to
land yet and it should help Windows PGO runs in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D37807
--HG--
extra : moz-landing-system : lando
Credit: Callek for figuring out an issue in 'make check' making the binary
absolute in mozbuild.base.
Differential Revision: https://phabricator.services.mozilla.com/D37319
--HG--
extra : moz-landing-system : lando
I couldn't use 'mach vendor python' to get this module in-tree because that
puts a 'backports' module on the PYTHONPATH. This is a problem because many
(most?) compatibility backports also use a 'backports' library. So in the
likely event that a user happens to have one of these installed in their
system Python, we'll search that module before the vendored one and fail to
find it.
This gets around the issue by foregoing 'backports' and just putting
'shutil_which' on the path
Differential Revision: https://phabricator.services.mozilla.com/D36838
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
--disable-verify-mar is kept to still allow to disable mar verification in
the updater for debugging purpose.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
We need a fix from `cctools-port` master for cross-language LTO builds
to work properly on the Mac. Rather than cherry-picking yet another
commit, which would have to deal with a updated `ld64` upstream, we've
opted to go ahead and update directly to upstream.
This choice brings about some significant build changes, as TAPI support
has moved to a different library that is not easily buildable directly.
Differential Revision: https://phabricator.services.mozilla.com/D36636
--HG--
extra : moz-landing-system : lando
As it turns out, the version the minidump-stackwalk tasks use (1.31), is
the first version that actually builds the project: 1.30 and earlier
fail because for some reason, cargo wants to read all Cargo.toml files
in the workspace, including unrelated ones, and barfs on features that
weren't supported until 1.31.
Differential Revision: https://phabricator.services.mozilla.com/D37020
--HG--
extra : moz-landing-system : lando
When building Gecko/Android/aarch64 on Windows, `--target` parameter may not be incorrect value. Although `check_compiler`'s `info` is target compiler, clang on Windows is always detected as `clang-cl`, not `clang`.
```
c:/Users/mkato/.mozbuild/clang/bin/clang.exe -E -dM - < /dev/null
...
#define _MSC_VER 1916
```
So even if using clang on Windows, not clang-cl, we should detect as 'clang' correctly
Differential Revision: https://phabricator.services.mozilla.com/D36422
--HG--
extra : moz-landing-system : lando
When host and target are different compiler type, triple for rustc may be incorrect. If target is clang, host is always clang, not using host compiler type.
Example, when host is clang-cl for windows, and target is clang for Android, host's triple for ructc sets `windows-gnu`, not `windows-msvc`.
Differential Revision: https://phabricator.services.mozilla.com/D36421
--HG--
extra : moz-landing-system : lando
Bug 1451104 removed the GCC 4.9 toolchain, but left the build script and
the patch that only that toolchain build was using.
Differential Revision: https://phabricator.services.mozilla.com/D36886
--HG--
extra : moz-landing-system : lando
When building Gecko/Android/aarch64 on Windows, `--target` parameter may not be incorrect value. Although `check_compiler`'s `info` is target compiler, clang on Windows is always detected as `clang-cl`, not `clang`.
```
c:/Users/mkato/.mozbuild/clang/bin/clang.exe -E -dM - < /dev/null
...
#define _MSC_VER 1916
```
So even if using clang on Windows, not clang-cl, we should detect as 'clang' correctly
Differential Revision: https://phabricator.services.mozilla.com/D36422
--HG--
extra : moz-landing-system : lando
When host and target are different compiler type, triple for rustc may be incorrect. If target is clang, host is always clang, not using host compiler type.
Example, when host is clang-cl for windows, and target is clang for Android, host's triple for ructc sets `windows-gnu`, not `windows-msvc`.
Differential Revision: https://phabricator.services.mozilla.com/D36421
--HG--
extra : moz-landing-system : lando
The SDK headers may not be installed in /usr/include. The usual response
has been to have people run e.g. `open
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg`
which is not really sustainable.
This makes builds that happen on a macOS host try to detect their SDK
and use that as a default for --with-macos-sdk, which has the side
effect of enabling the SDK version check in that configuration.
Differential Revision: https://phabricator.services.mozilla.com/D36558
--HG--
extra : moz-landing-system : lando
Building host tools on macOS require a macOS SDK, but it's currently
not configurable when cross-compiling for e.g. Android.
Differential Revision: https://phabricator.services.mozilla.com/D36557
--HG--
extra : moz-landing-system : lando
The SDK headers may not be installed in /usr/include. The usual response
has been to have people run e.g. `open
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg`
which is not really sustainable.
This makes builds that happen on a macOS host try to detect their SDK
and use that as a default for --with-macos-sdk, which has the side
effect of enabling the SDK version check in that configuration.
Differential Revision: https://phabricator.services.mozilla.com/D36558
--HG--
extra : moz-landing-system : lando
Building host tools on macOS require a macOS SDK, but it's currently
not configurable when cross-compiling for e.g. Android.
Differential Revision: https://phabricator.services.mozilla.com/D36557
--HG--
extra : moz-landing-system : lando
LLVM r356397 added some new warnings to the compiler that in this file complain about `size argument is too large; destination buffer has size 100, but size argument is 101`.
The easiest path is to just remove those lines; doing so doesn't really weaken the test coverage of the SprintfLiteral checker.
Differential Revision: https://phabricator.services.mozilla.com/D36515
--HG--
extra : moz-landing-system : lando
LLVM r356397 added some new warnings to the compiler that in this file complain about `size argument is too large; destination buffer has size 100, but size argument is 101`.
The easiest path is to just remove those lines; doing so doesn't really weaken the test coverage of the SprintfLiteral checker.
Differential Revision: https://phabricator.services.mozilla.com/D36515
--HG--
extra : moz-landing-system : lando
I don't know if this covers all the things that use mozinfo (probably not)
but it covers all the suites that use mozinfo and have webrender conditions
in the test manifests (i.e. mochitest and wpt variants).
Differential Revision: https://phabricator.services.mozilla.com/D35869
--HG--
extra : moz-landing-system : lando
The condition that enabled ELOG to do something has been broken since
bug 279212 landed two years ago, because MAKEFLAGS doesn't contain the
dash for flags, so looking for "-s" never did anything.
Bug 1560527 changed the condition to !BUILD_VERBOSE_LOG, which as of the
previous commit, does work. This would restore the old behavior, at the
expense of build time, since it involves wrapping in a shell script,
which is not necessarily desirable (and hasn't been done for two years
now)
Differential Revision: https://phabricator.services.mozilla.com/D35967
--HG--
extra : moz-landing-system : lando
With clang-cl and PGO enabled, toolchain.configure automatically turns
on LTO for compatibility with MSVC. However, MOZ_PGO is set for both the
profile-generate and profile-use builds in a 3-tier PGO setup via
imply_option(), but we only want LTO enabled for the profile-use build
(see bug 1483778).
For 1-tier PGO builds, which are still used by local developers, MOZ_PGO
will be set and --enable-profile-generate will be unset, so LTO will be
automatically enabled. The profiledbuild target in make is responsible
for disabling MOZ_LTO on the profile-generate build.
For 3-tier PGO builds, MOZ_PGO will still be set, so we can skip setting
LTO in configure when --enable-profile-generate is set.
Differential Revision: https://phabricator.services.mozilla.com/D34800
--HG--
extra : moz-landing-system : lando
Windows finds llvm-profdata in the PATH, in contrast to Linux or Android
builds that set LLVM_PROFDATA as an environment variable in mozconfigs.
The pgo_profile_path() configure checks should still work in this case.
Differential Revision: https://phabricator.services.mozilla.com/D34799
--HG--
extra : moz-landing-system : lando
MOZ_PGO_PROFILE_USE is set when the use-pgo attribute is defined in the
task. This environment variable is used to enable --enable-profile-use
and related configure flags.
Differential Revision: https://phabricator.services.mozilla.com/D34798
--HG--
extra : moz-landing-system : lando
In the clang-cl 9 case where we have semicolon-separated paths, the `dirs` variable is never read, so the libclang detection fails.
Differential Revision: https://phabricator.services.mozilla.com/D35825
--HG--
extra : moz-landing-system : lando
This is a simple mach command that imports a PR from a whitelisted set
of github repositories into the local m-c clone. It works by downloading
the .patch file from github, splitting the different commits, and
applying those commits to the local repo via the `patch` tool and git/hg
commit. It optionally allows filing a bug or providing a bug number, and
specifying a reviewer.
This is one part of a larger workflow that facilitates landing
contributor patches into m-c when those patches are submitted as PRs.
Other components of the workflow (to be added in the future) will make
it easier to actually test and land the patch.
Differential Revision: https://phabricator.services.mozilla.com/D35206
--HG--
extra : moz-landing-system : lando
- `info.type in ('clang-cl', 'clang', 'gcc')` is always true since MSVC
support was removed.
- For some reason, we didn't enforce C++14 on GCC.
Differential Revision: https://phabricator.services.mozilla.com/D34990
--HG--
extra : moz-landing-system : lando
Improve support for Python 3 by running modernize over adb.py and a few other related changes.
Differential Revision: https://phabricator.services.mozilla.com/D19306
--HG--
extra : moz-landing-system : lando
We've been relying on frame pointers being indirectly enabled via things
like --enable-profiling for some time, but this doesn't scale because
some things may want frame pointers while wanting --disable-profiling.
So we move MOZ_FRAMEPTR_FLAGS to python configure and add a new option
to decide whether to enable frame pointers or not.
Differential Revision: https://phabricator.services.mozilla.com/D34117
--HG--
extra : moz-landing-system : lando
Bug 1394825 bumped the minimum version of clang we use on automation,
for the base toolchain jobs, and there's a libclang test for bindgen,
but we should reject the compiler in the first place.
The check to do that works in both C and C++, contrary to the original
3.6 test that was checking a C++ feature ; the test was later changed
for 3.9, using a check that would have worked in both C and C++, but
the C exception was left around. We remove it now.
Differential Revision: https://phabricator.services.mozilla.com/D34083
--HG--
extra : moz-landing-system : lando
Stand-alone JS builds now default to without-NSPR on all platforms.
Note that the JS shell builds we do in automation pass --enable-nspr-build so they shouldn't be affected by
the JS shell changes.
Differential Revision: https://phabricator.services.mozilla.com/D33933
--HG--
extra : moz-landing-system : lando
Use the same logic as for --with-android-sdk to use the NDK downloaded
by mach bootstrap by default.
Differential Revision: https://phabricator.services.mozilla.com/D34251
--HG--
extra : moz-landing-system : lando
We make it have a default value only if the corresponding directory exists,
and make it throw a more explicit error when the explicitly given directory
doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D34250
--HG--
extra : moz-landing-system : lando
The current logic is that if the compiler somehow uses gold rather than
BFD ld by default, we let it, but if it uses BFD ld, we default to lld.
When doing Android builds, the compiler finds the linker in the NDK, and
the default `ld` binary is gold. So we currently end up using fold for
Android builds.
Here, we change the logic such that we use lld when the default linker
the compiler uses is either BFD ld or gold. We can't go with "is not
lld" because the other possible kind, ld64, is what we actually want to
use on mac, since lld doesn't support mach-o fully just yet.
Differential Revision: https://phabricator.services.mozilla.com/D34040
--HG--
extra : moz-landing-system : lando
The current logic is that if the compiler somehow uses gold rather than
BFD ld by default, we let it, but if it uses BFD ld, we default to lld.
When doing Android builds, the compiler finds the linker in the NDK, and
the default `ld` binary is gold. So we currently end up using gold for
Android builds.
Here, we change the logic such that we use lld when the default linker
the compiler uses is either BFD ld or gold. We can't go with "is not
lld" because the other possible kind, ld64, is what we actually want to
use on mac, since lld doesn't support mach-o fully just yet.
Differential Revision: https://phabricator.services.mozilla.com/D34040
--HG--
extra : moz-landing-system : lando
https://reviews.llvm.org/rL360311 reworked the handling of `explicit` in `CXXConversionDecl`, and the `isExplicitSpecified()` method no longer exists. We can instead use `isExplicit()` which conveniently works on both old and new clangs. (Before 360311, `isExplicit()` just forwarded to `isExplicitSpecified()`.)
Differential Revision: https://phabricator.services.mozilla.com/D33958
--HG--
extra : moz-landing-system : lando
Valgrind report:
```
TEST-UNEXPECTED-FAIL | valgrind-test | 192 bytes in 3 blocks are definitely lost at malloc / dl_open_worker / _dl_catch_error / _dl_open
==2561== 192 bytes in 3 blocks are definitely lost in loss record 348 of 399
==2561== at 0x4C2B240: malloc+112 (vg_replace_malloc.c:298)
==2561== by 0x4012919: dl_open_worker+1977 (dl-open.c:457)
==2561== by 0x400DD55: _dl_catch_error+101 (dl-error.c:178)
==2561== by 0x4011CC9: _dl_open+185 (dl-open.c:633)
==2561== by 0x5051F65: dlopen_doit+101 (dlopen.c:67)
==2561== by 0x400DD55: _dl_catch_error+101 (dl-error.c:178)
==2561== by 0x50522EB: _dlerror_run+123 (dlerror.c:164)
==2561== by 0x5051EE0: dlopen@@GLIBC_2.2.5+48 (dlopen.c:88)
==2561== by 0x1148FC: GetLibHandle (xpcom/glue/standalone/nsXPCOMGlue.cpp:86)
==2561== by 0x1148FC: ReadDependentCB (xpcom/glue/standalone/nsXPCOMGlue.cpp:136)
==2561== by 0x1148FC: XPCOMGlueLoad (xpcom/glue/standalone/nsXPCOMGlue.cpp:306)
==2561== by 0x1148FC: mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy)+572 (xpcom/glue/standalone/nsXPCOMGlue.cpp:374)
==2561== by 0x114213: InitXPCOMGlue(mozilla::LibLoadingStrategy)+131 (browser/app/nsBrowserApp.cpp:223)
==2561== by 0x113E6B: main+219 (browser/app/nsBrowserApp.cpp:284)
```
Nothing due directly to this patch, so it is likely a dlopen issue.
Differential Revision: https://phabricator.services.mozilla.com/D33904
--HG--
extra : moz-landing-system : lando
The current setup for bindgen relies on either finding clang/libclang
from the output of llvm-config, or from the paths given via the
configure flags --with-clang-path/--with-libclang-path.
One _very_ common problem is that the llvm-config we end up using does
not correspond to the clang used for compilation, which has some
undesirable side effect, like failing to build.
So instead of relying on llvm-config, we do the following:
- when the compiler is clang, we just use that
- when the compiler is clang-cl, we use clang from the same directory
- otherwise, we either try to find clang in PATH, or rely on
--with-clang-path.
Once clang is found, we try to deduce the location of the corresponding
libclang via the output of `clang -print-search-dirs`, or rely on
--with-libclang-path.
Differential Revision: https://phabricator.services.mozilla.com/D33241
--HG--
extra : moz-landing-system : lando
Inheriting constructors are implicitly introduced via a using-declaration.
Since the C++ grammar doesn't allow attributes on using-declarations, it
is currently impossible to add MOZ_IMPLICIT to implicit inheriting
constructors.
This commit changes the AST matcher such that it ignores inheriting
constructors altogether. If they are inheriting from an implicit inherited
constructor, that constructor's check should be enough to ensure that no
constructors are unintentionally implicit.
Differential Revision: https://phabricator.services.mozilla.com/D33281
--HG--
extra : moz-landing-system : lando
This code was already dead during the VS2017 era (since that compiler changed to the `Hostx64\x86` path scheme), let alone clang-cl.
Differential Revision: https://phabricator.services.mozilla.com/D33513
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
This change is a little bit of a cheat, because of course MSVC doesn't
do cross-language LTO by default, but it seems consistent.
Depends on D33317
Differential Revision: https://phabricator.services.mozilla.com/D33318
--HG--
extra : moz-landing-system : lando
- DISABLE_SHARED_JS and DISABLE_EXPORT_JS have been deprecated for 3
years,
- MOZ_JEMALLOC4 has been deprecated for 2 years.
Differential Revision: https://phabricator.services.mozilla.com/D32928
--HG--
extra : moz-landing-system : lando
Negative value for import level is obsolete in Python 3, which was used on Py2 for implicit relative import. This change ensures the level value to be >=0 on Py3 to fix test failures.
Differential Revision: https://phabricator.services.mozilla.com/D32497
--HG--
extra : moz-landing-system : lando
The exit code from valgrind may subtly indicate how it failed (like, if
it's 139 or 137, which would mean respectively segfault or killed by
something external), which is currently completely hidden, making
diagnostics of things like bug 1545094 harder.
Differential Revision: https://phabricator.services.mozilla.com/D32412
--HG--
extra : moz-landing-system : lando
We're moving to IR-level PGO instrumentation for clang-cl. We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation. We therefore
we no longer need this code.
Differential Revision: https://phabricator.services.mozilla.com/D31134
--HG--
extra : moz-landing-system : lando
This form of instrumentation is more like our other platforms, and also
opens the possibility of interacting properly with Rust IR-level PGO.
Differential Revision: https://phabricator.services.mozilla.com/D31133
--HG--
extra : moz-landing-system : lando
We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
e10s profiling or IR-based PGO instrumentation will both produce
multiple `.profraw` files that need to be handled in some way. Since
clang's `-fprofile-generate` option takes a directory, it seems fitting
to make `--with-pgo-profile-path` mirror that by taking a directory, and
letting `merge_profdata.py` deal with whatever files it might find in
said directory.
Differential Revision: https://phabricator.services.mozilla.com/D32389
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This will match the compiler version Tor would like. We backport several
llvm-objcopy patches that landed right after the 8 branch though. We
also grab some upstream changes from mingw-clang in the build script
Differential Revision: https://phabricator.services.mozilla.com/D31347
--HG--
extra : moz-landing-system : lando
Bug 1548941 restricted under which circumstances we allow the
browser.tabs.remote.autostart pref to turn off e10s. The PGO profileserver.py
script relied on the unittest-required user.js prefs collection to turn off
e10s (see also bug 1196094) via this pref. For PGO builds, we do not set the
MOZ_DISABLE_NONLOCAL_CONNECTIONS env var, which meant that we stopped
honouring the pref to turn off e10s. Unfortunately, this meant that
e10s was inadvertently now switched on for the pgo profiling, which
negatively impacted speedometer on PGO builds (and possibly other tests).
All this change does is re-disable e10s for PGO profiling. We should
investigate how to turn e10s on "properly" for PGO, but we can do that in
bug 1196094, without taking this temporary regression, especially as 68
branches.
Differential Revision: https://phabricator.services.mozilla.com/D31736
--HG--
extra : moz-landing-system : lando
We need this to auto-generate the copy-constructor for TransformOperation,
without which the patch wouldn't build.
Differential Revision: https://phabricator.services.mozilla.com/D30799
--HG--
extra : moz-landing-system : lando
Having `rustc` be `rustup`'s wrapper for `rustc` means that we may
silently honor `rustup`'s override mechanisms. We noticed this first on
OS X, where we use the "real" `cargo` but `rustup`'s `rustc` wrapper,
and problems ensued when `cargo` thought it was using one version of
`rustc`, but actually wound up using something different.
It seems better to avoid silently interposing `rustup`'s toolchain
override mechanisms everywhere, rather than having to special-case OS
X. So let's factor out a general mechanism for removing the wrappers
`rustup` provides and use that for both `rustc` and `cargo`. The tests
need adjusting because we weren't triggering the unwrapping cases
before; we don't yet test the case where we really do need to unwrap.
That test can be left for a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D29531
--HG--
extra : moz-landing-system : lando
We've not been checking the clang-cl version in use. This lack of
checking is bad, for a couple of reasons:
* Released versions of clang-cl differ drastically in their robustness;
* Only the most recent version of clang-cl supports aarch64.
We should check for a minimum version of clang-cl, just like our other
supported compilers. As a bonus, we can then start depending on
features that we know appear in the particular minimum clang-cl
version. (The current patch is motivated by `/clang:` command-line
support, but one could pick other things.)
Differential Revision: https://phabricator.services.mozilla.com/D30723
--HG--
extra : moz-landing-system : lando
This option is for performing LTO between C++ code and Rust code. The
actual build pieces for Rust code are coming in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D28508
--HG--
extra : moz-landing-system : lando
We already do this for the compiler that we detect via
toolchain.configure...but as the comment in `basic_bindgen_cflags`
alludes to, we don't actually use that compiler here. We use a much
more bare-bones compiler, so we have to add the necessary flags manually.
We need to make `--with-macos-sdk` a `js_option` so that uses of bindgen
in the JS engine will receive the proper flags.
Differential Revision: https://phabricator.services.mozilla.com/D30239
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
