While here, we switch to using an alias to make such changes easier in
the future. This will also ensure that CI builds and bootstrap use the
same one.
Differential Revision: https://phabricator.services.mozilla.com/D177717
Because this involves affecting the MSVC + Windows SDK packs, we need to
do this for toolchain tasks as well as Firefox builds in a single pass.
The MSVC + Windows SDK packs are altered to keep the original case
instead of lowercasing everything (except .lib files), and contain
an overlay file that we now automatically use from the WINSYSROOT.
This requires adjusting some paths to match what the original case
is, as well as removing everything related to the use of liblowercase,
which conflicts with the use of the overlay file. People using
liblowercase locally will still have a working setup as long as they
don't set WINSYSROOT (it's new, so they won't have it), and don't have
an overlay file in there (which they only would if they ran the new
pack_vs.py).
Differential Revision: https://phabricator.services.mozilla.com/D165596
Cleans up the interface to AudioSession and brings in line with COM best practices. Uses background threads that are implicitly MTA and asserts proper thread behavior. This also removes AudioSession's Co[Un]Initialize static analysis violations.
Differential Revision: https://phabricator.services.mozilla.com/D140741
Pointer to AudioSession object is made std::atomic to resolve crashes (bug 1755700) by atomically modifying/reading the pointer as an effort to make sure any update to the pointer is seen across other threads immediately while not using locks to maintain such concurrency and avoiding dataraces.
This patch is built upon the work done in D136377.
Differential Revision: https://phabricator.services.mozilla.com/D140741
The llvm-symbolizer tasks currently extract a llvm-symbolizer from clang
tasks. Changes in clang 14 make the hack that we have in place to keep
llvm-symbolizer statically linked to libllvm while clang uses a dynamic
libllvm not work anymore, so it's time to bite the bullet and build
llvm-symbolizer separately.
We share most of the build setup with the compiler-rt build.
Differential Revision: https://phabricator.services.mozilla.com/D140711
It was added for llvm-symbolizer, and at the time, it was required.
However, since [1] (shipped in llvm 12), llvm-symbolizer, msdia140.dll
is not used by default, only when passing the -dia command line option,
which we don't use.
1. c74b427cb2
Differential Revision: https://phabricator.services.mozilla.com/D136821
`Layer::GetDisplayListLog()` also still contains the metion to
LayerScope to dump display list.
But this change does not remove it because it's a part of debugging display list.
If we remove it, I think we should open a new bug for it.
Differential Revision: https://phabricator.services.mozilla.com/D126512
There are two big parts in the MSVC toolchain we use:
- the Windows 10 SDK
- Visual C++
For the former, both the 15.8.4 and 15.9.6 toolchains are using the same
version of the Win10 SDK.
For the latter, we're not using the compiler itself anymore, so the only
substantial difference is in the headers and libraries included with
Visual C++, as well as the redist libraries for the CRT. Both versions
are supposed to be compatible to the same set of OS versions, fitting
our system requirements.
This makes us use the same version of MSVC on all our Windows builds
(arm64 builds were already on 15.9.6).
Differential Revision: https://phabricator.services.mozilla.com/D123720
As far as I can see, all this does is protect the user from
running some useless code if they manually enable the priority
manager using a pref on an OS that doesn't support it. The
upside of allowing this is that it makes it possible to debug
the priority manager on OSX and Linux with just a pref flip.
Differential Revision: https://phabricator.services.mozilla.com/D114767
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
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
Since bug 1632542 we have a new major clang version, several new versions worth of rustc, new pass manager during LTO, and of course eight months worth of code change. Time for a refresh. Same process as the earlier bug.
Differential Revision: https://phabricator.services.mozilla.com/D99243