The new task builds a stage 2 compiler and uses it to generate the
profile as stage 3, and the profile is used to feed the now separate
stage 4 clang build. This will allow us to use this same profile to
build mac clangs with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D138511
The patch conflicts with latest clang trunk changes.
It was necessary back when we started using clang-cl instead of MSVC,
and we needed to fallback to MSVC for sources that clang-cl couldn't
build. Nowadays, with cross-compiles, that fallback can't happen
anyways, and even on native Windows builds we never use cl.exe.
Differential Revision: https://phabricator.services.mozilla.com/D138615
llvmorg-13-init-8182-gc2297544c047 was finally backed out upstream which
means we don't need to revert it or its followups
(llvmorg-14-init-3651-g85ba583eba19 and llvmorg-14-init-3652-gf3c2094d8c11)
Differential Revision: https://phabricator.services.mozilla.com/D138399
This means we can now skip building a 32-bit compiler-rt when building
clang itself, as well as the asan pdb files, which will be taken from
the compiler-rt artifact.
Differential Revision: https://phabricator.services.mozilla.com/D137259
As of bug 1751824, the only remaining use of the 2-stages Windows clang
toolchain is for llvm-profdata in the generate-profile runs.
We don't need that to be built by clang itself (whereas it was desirable
to get compiler-rt from stage 2 before bug 1751824), so we can drop that
build to one stage only.
And because as of bug 1751839 we can start building stage 2 from a
separate stage 1 task, we do that for the Windows clang toolchain, like
we do for the Linux one.
Also, make the win64-clang-toolchain alias point to that stage 1 build,
like for Linux.
Differential Revision: https://phabricator.services.mozilla.com/D137257
This reduces some code duplication and paves the way for modifying how
Mach loads modules.
The plan is to follow this up by making this function take a more fleshed out 'spec'
that maps command names to the files they're defined at and possibly more metadata.
Since this may affect how Mach works internally (e.g. with lazy loading in the roadmap),
it makes sense to move this logic inside the Mach class.
Differential Revision: https://phabricator.services.mozilla.com/D136789
`MOZ_KNOWN_LIVE RefPtr<Foo> mFoo` is not treated as safe because its raw pointer
is referred with operators but they are not checked at handling `MOZ_KNOWN_LIVE`
annotation.
Additionally, when members marked as `MOZ_KNOWN_LIVE` are in the stack, they
are also not treated as safe, but they should be safe in most cases.
With these changes, `HTMLTableEditor.cpp` can get rid of a lot of
`MOZ_KnownLive` method calls.
Differential Revision: https://phabricator.services.mozilla.com/D136122
Back when this was added, clang's default mode might have been c++11,
but it's not c++17, and we're effectively downgrading it (which
incidentally causes problems to build libc++).
Differential Revision: https://phabricator.services.mozilla.com/D137255
It doesn't appear like the breaking changes will affect us.
Note that the taskcluster packages config wasn't updated because
`0.17.0` hasn't yet been deployed to the GitHub releases page.
Differential Revision: https://phabricator.services.mozilla.com/D136947
This avoids needing clang-cl.exe on cross compilations. We could keep
Windows builds on having MIDL do the preprocessing, but that would be
a difference between native and cross builds, and it's better to avoid
that.
Differential Revision: https://phabricator.services.mozilla.com/D136831
This allows to start building other toolchains, compiler runtimes, much
earlier, since we don't have to wait for a complete 4-stage-optimized
compiler to start these, while the output produced by clang is
presumably the same whether it's a stage 1 or a stage 4 clang.
Differential Revision: https://phabricator.services.mozilla.com/D136844
It is currently enabled automatically because libxml2 is detected, but
we want to be sure it's not accidentally disabled.
Differential Revision: https://phabricator.services.mozilla.com/D136840
`extra_targets` was used for the aarch64-linux compiler runtime, which
moved to a separate task in bug 1690757, and `android_targets` was used
for android compiler runtimes, which moved to separate tasks in
bug 1690973.
Using separate tasks is now the prefered way to build compiler runtimes,
os we won't need these options.
Differential Revision: https://phabricator.services.mozilla.com/D136822
