We only generate a single orderfile and use it for each linked object,
which results in some symbols being listed while not belonging to that
particular object.
Differential Revision: https://phabricator.services.mozilla.com/D197621
Ideally, we wouldn't rely on tooltool, but until we can have private
fetches that can actually be used forever without having to be
retriggered for CoT or other reasons, tooltool is the best we have.
Differential Revision: https://phabricator.services.mozilla.com/D197305
The first thing is that the target CPU may not be supported by Visual
C++, so using that, we don't find the path to a Visual C++ compiler.
By using the host CPU in that case, we can find it.
For ATL and MFC libraries, we may not be able to find them for similar
reasons, but we don't actually need them when cross-compiling, so just
return nothing for those when the target OS is not Windows.
Differential Revision: https://phabricator.services.mozilla.com/D197037
It's not like we publish the ReleaseNotes from the clang toolchain
artifact, and it's only going to be a recurrent source of patch conflict
when the upstream release notes change.
Differential Revision: https://phabricator.services.mozilla.com/D196529
We use UPLOAD_DIR rather than UPLOAD_PATH because UPLOAD_DIR is handled
by run-task to be set properly from a relative path.
As the snaps rightfully unset MOZ_AUTOMATION, we add another way to
enable the use of the symbols server.
Differential Revision: https://phabricator.services.mozilla.com/D196399
AC_SUBSTs with a lower-case key are not really supposed to be used,
although that has never been enforced, and at least one of them is
used in practice.
At least, that's the theory behind using files to store their value in
config.statusd (added in bug 1402012). Because obviously, on
case-insensitive file systems, a variable that is upper case will use
the same file as the lower case one. If their value is the same, then
fine, but if they aren't, thing go bad.
Until bug 1867457, that held true for TARGET_CPU and target_cpu: their
value was the same. But bug 1867457 changed that. But target_cpu is only
there because it's set by autoconf itself, and we don't care about it.
The result is that the value of target_cpu takes precedence because it's
set last, and overwrites the value of TARGET_CPU in config.statusd,
subsequently making the value read in GenerateAtomicOperations.py wrong.
Differential Revision: https://phabricator.services.mozilla.com/D195959
AC_SUBSTs with a lower-case key are not really supposed to be used,
although that has never been enforced, and at least one of them is
used in practice.
At least, that's the theory behind using files to store their value in
config.statusd (added in bug 1402012). Because obviously, on
case-insensitive file systems, a variable that is upper case will use
the same file as the lower case one. If their value is the same, then
fine, but if they aren't, thing go bad.
Until bug 1867457, that held true for TARGET_CPU and target_cpu: their
value was the same. But bug 1867457 changed that. But target_cpu is only
there because it's set by autoconf itself, and we don't care about it.
The result is that the value of target_cpu takes precedence because it's
set last, and overwrites the value of TARGET_CPU in config.statusd,
subsequently making the value read in GenerateAtomicOperations.py wrong.
Differential Revision: https://phabricator.services.mozilla.com/D195959
In many cases, using CONFIG["CPU_ARCH"] will silently do the unexpected
thing now that it doesn't exist anymore. In case there are in-flight
patches using it, it's better to avoid those causing subtle problems
after a rebase by making most uses of the variable throw an exception.
Differential Revision: https://phabricator.services.mozilla.com/D195158
This is 5% faster on my setup, mostly thanks to unrolling being
possible.
We also skip the early loop exit. Most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations if we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Only activated on non-Android target though, as it breaks at runtime.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
Introduce functions which create and invoke the Windows file-picker in a
separate thread. This thread is created with a new single-threaded COM
apartment to avoid implicitly creating a nested modal loop on the main
STA thread.
Technically, no functional changes: these functions aren't actually
invoked yet. (That will occur in an upcoming commit.)
Differential Revision: https://phabricator.services.mozilla.com/D193735
