Passing all the directories to mach allows to take more advantage of
parallelism (plus not having to start up mach and the whole export once
for every directory, which itself takes a bit of time)
This takes:
GECKO_PATH=. taskcluster/scripts/misc/source-test-clang-non-unified.sh
from about ten mins to under two minutes on my machine.
Differential Revision: https://phabricator.services.mozilla.com/D101320
Now that linux64-clang-11-macosx-cross doesn't need a macosx64-clang-*
to build, there is no circular dependency to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D101080
The new toolchain contains both aarch64 and x86_64 compiler-rts. We
could have a separate for each, but compiler-rt is small enough that
entirely separate toolchains is not warranted.
Differential Revision: https://phabricator.services.mozilla.com/D101079
The llvm build system does support building a universal compiler-rt for
multiple platforms at once, but as far as I know it only supports doing
so with the same SDK, while we want to use separate SDKs for each, so
build the x86_64 compiler-rt separately.
Differential Revision: https://phabricator.services.mozilla.com/D101078
We actually don't need the macosx-cross toolchain to build compiler-rt,
because building compiler-rt doesn't require compiler-rt (duh).
Differential Revision: https://phabricator.services.mozilla.com/D101077
The webrender wrench macos build, which is cross-compiled, needs a
macOS native libLLVM (a .dylib) to link against. The file is currently
part of the macosx-cross toolchain, but that was more incidental than
intentional. As we're going to change the macosx-cross toolchain in a
way that will remove the libLLVM.dylib, pull the file from the macOS
native clang.
Differential Revision: https://phabricator.services.mozilla.com/D101150
Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
Now that linux64-clang-11-macosx-cross doesn't need a macosx64-clang-*
to build, there is no circular dependency to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D101080
The new toolchain contains both aarch64 and x86_64 compiler-rts. We
could have a separate for each, but compiler-rt is small enough that
entirely separate toolchains is not warranted.
Differential Revision: https://phabricator.services.mozilla.com/D101079
The llvm build system does support building a universal compiler-rt for
multiple platforms at once, but as far as I know it only supports doing
so with the same SDK, while we want to use separate SDKs for each, so
build the x86_64 compiler-rt separately.
Differential Revision: https://phabricator.services.mozilla.com/D101078
We actually don't need the macosx-cross toolchain to build compiler-rt,
because building compiler-rt doesn't require compiler-rt (duh).
Differential Revision: https://phabricator.services.mozilla.com/D101077
Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
In addition to the usual dot-release type of fixes, this also lets us drop a good amount of code that we had patched into our clang 11.
Differential Revision: https://phabricator.services.mozilla.com/D100959
Bug 1683824 updated to the 0.2.14 tag, but that's patched in order to
publish to crates.io such that tiny-http is not patched anymore.
Unfortunately, that breaks sccache-dist, which is a known issue and will
eventually fixed when addressing
https://github.com/mozilla/sccache/issues/912.
So here we update to a corresponding version on master (the first that
bumps the version to the next number).
Differential Revision: https://phabricator.services.mozilla.com/D100863
I was waiting for a better reason to do this, because the cbindgen
changes from 0.15.0 to 0.16.0 don't break trunk builds. But since
downstream has updated (see bug 1684180) and there's no reason not to,
let's do this to avoid future churn.
Differential Revision: https://phabricator.services.mozilla.com/D100499
Since e10s-multi is going to be enabled by default, this gives us the ability
to run junit in a secondary, e10s-single configuration so that we can see them
both side-by-side for a little while, at least until we're settled in with the
e10s-multi configuration.
Differential Revision: https://phabricator.services.mozilla.com/D94883
When building compiler-rt for macOS, its build system assumes the
compiler used is a native macOS clang, drops all the cmake C/C++ flags,
and adds its own.
Because we do need to pass `-target $target` (otherwise we end up with
ELF x86_64 objects) and `-mcpu=apple-a12` for the correct baseline for
arm64 macOS, and because there is unfortunately no cmake variable that
the compiler-rt build system will use, and because CMAKE_C*_COMPILER
need to be a program without arguments, we need to wrap the compiler.
While here, add `-v` to the ninja call to have more useful logs.
Differential Revision: https://phabricator.services.mozilla.com/D99841
This patch enables ASan for rust code in the `linux64-asan/{debug,opt}` and `linux64-asan-fuzzing` build tasks. Since it is a `-Z` unstable flag, we'll move to the same `linux64-rust-nightly` toolchain that TSan builds use.
For the time being, the ASan Nightly Reporter builds are left alone, until we're more familiar with the perf impacts of this landing.
Differential Revision: https://phabricator.services.mozilla.com/D99556
At this point it's pretty clear that we won't be reverting to clang-9.
This doesn't remove everything with clang-9 in the name. I did a mark-and-sweep GC by hand so this only removes unused entries. Some are still active, e.g. linux64-clang-9 is used to build a number of misc helper tools.
Differential Revision: https://phabricator.services.mozilla.com/D99721