If a TLS server asks for a client authentication certificate, no dialog asking
the user to select one should be shown until the server's certificate verifies
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D175170
If a TLS server asks for a client authentication certificate, no dialog asking
the user to select one should be shown until the server's certificate verifies
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D175170
This requires a couple backports from clang trunk:
- one for https://github.com/llvm/llvm-project/issues/60109
- one to replace revert-llvmorg-15-init-17171-g8bb4451a651a.patch, which
addresses the regression rather than reverting it.
clang_include_cleaner.patch is also disabled in clang-tidy, as the patch
doesn't apply anymore, and the check it adds is not enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D173106
Using the newer version of the crash-context crate corrects the 32-bit Linux context structure,
which was the cause of the IP memory not being stored (among possibly other 32-bit Linux issues).
Differential Revision: https://phabricator.services.mozilla.com/D174314
For preparation of bug 1620312, CanRunScriptChecker needs to allow references
which are initialized with safe instance(s) to run script. Unfortunately,
this does not allow references which are initialized with safe references
recursively because it requires more complicated checks but it must be not
used in many places.
Differential Revision: https://phabricator.services.mozilla.com/D174436
gemmology is a rewrite of intgemm based on xsimd (that we already
vendor), with a focus on the API we actually use.
It also supports sse2 and has a decent implementation for arm32 and
aarch64.
This patch integrates sse2, ssse3 and avx2 support.
Differential Revision: https://phabricator.services.mozilla.com/D171265
gemmology is a rewrite of intgemm based on xsimd (that we already
vendor), with a focus on the API we actually use.
It also supports sse2 and has a decent implementation for arm32 and
aarch64.
Differential Revision: https://phabricator.services.mozilla.com/D171265
gemmology is a rewrite of intgemm based on xsimd (that we already
vendor), with a focus on the API we actually use.
It also supports sse2 and has a decent implementation for arm32 and
aarch64.
Differential Revision: https://phabricator.services.mozilla.com/D171265
Before clang 16, the libunwind install only contained the libunwind.a
library. Since clang 16, however, it also contains header files,
including a unwind.h file that conflicts with the unwind.h file that
is also shipped alongside compiler-rt.
When building clang itself with compiler-rt and libunwind (i.e. not
building everything separately like we do), however, that's not a
problem because it puts libunwind in a different directory than
compiler-rt.
So we change the clang repacking to follow a similar convention.
But because clang doesn't look for libraries under clang/lib/$arch, but
looks under clang/lib/$target instead, we also need to enable per-target
directories for libunwind.
But because clang also looks for libraries under clang/lib/$exact_target
rather than clang/lib/$relaxed_target (in Android's case, exact_target
might be aarch64-unknown-linux-android21, relaxed_target
aarch64-unknown-linux-android), we patch clang to apply the same kind of
fallbacks it does for runtimes for clang/lib.
Differential Revision: https://phabricator.services.mozilla.com/D173363
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
Notably, the actual attribution code we're using is stored in `browser`. This was largely motivated by the fact that the subsequent revision in this stack will also need it, and this seemed like the best way to make it shareable between the two. The only alternative I could come up with was stuffing it into a transforms - but it's really just data - there's no reason it ought to live in such a place. (We do have precedent for this sort of thing with both locale and whats new page information, so I don't think it's breaking huge new ground.) Nick - I'm tagging you mainly on this part, but I welcome any other comments you may have (here or in the rest of the stack for that matter).
The other notable part of this patch is that I've _explicitly_ decided not to use the `multi_dep` loader, nor reimplement any of its magic pulling of properties in a transform. I find that this makes it more clear what's _actually_ going on, and easier to debug when making changes. The dwonside, of course, is that there's some verboseness in the kind - all platforms we need to run this for must be explicitly listed. I'm open to debate on whether or not this is the right trade-off, so feel free to push back if you disagree.
Differential Revision: https://phabricator.services.mozilla.com/D170243
To replace our own patch, which now conflicts with clang trunk.
We don't build clang 14 for Windows, so we just remove the patch for
clang 14.
Differential Revision: https://phabricator.services.mozilla.com/D172059
This used to be necessary, but since we switched most things to use LLVM
tools instead of binutils ones, this has become less useful.
Differential Revision: https://phabricator.services.mozilla.com/D171956
VideoCapture used to be a base::Thread called VideoCapture.
DesktopCapture used to be a rtc::PlatformThread/PlatformUIThread called ScreenCaptureThread.
Differential Revision: https://phabricator.services.mozilla.com/D166061
This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
Bug 1805664 had the side effect of installing terminfo libraries on the
toolchain docker image, which led to clang gaining a dependency on
libtinfo, leading to multiple failures, like PGO run jobs failing with
llvm-profdata failing to load the new dependency, or tsan tests failing
because llvm-symbolizer doesn't work because of the new dependency not
being fulfilled, which in turn breaks TSAN suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D170417
We're going to (ab)use the configure scripts to get the right SDK
locations for msix repackaging, and it would be preferable to avoid
requiring the preprocessor for that.
Differential Revision: https://phabricator.services.mozilla.com/D170171
This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
This patch introduces:
1. fetch jobs to fetch python source / installer
2. a) build jobs to build python from source on Linux and OSX
b) build job to manually extract python tree from Windows installer
Some details, per category:
(1) fetches Python 3.8.10 (source) and 3.8.10 (installer).
(2.a) the builds generate optimized version of Python (LTO + PGO)
(2.a) the builds are patched to honor MOZPYTHONHOME instead of
PYTHONHOME. This is used to make OSX builds relocatable, and not
needed on Windows.
(2) zstandard and psutil are added to the default build
Differential Revision: https://phabricator.services.mozilla.com/D164663
We're soon going to introduce a new way to distinguish between the two
windows ABIs, so we factor out compiler checks that will need to be
adjusted to limit the amount of changes down the line.
Differential Revision: https://phabricator.services.mozilla.com/D170167
The patch was added back in bug 1661129 to work around
https://bugs.llvm.org/show_bug.cgi?id=47258 and the patch now doesn't
apply anymore after changes on clang trunk. OTOH, it also seems that the
problem described in the llvm bug report doesn't happen anymore, so just
get rid of the patch.
Differential Revision: https://phabricator.services.mozilla.com/D169292
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
Per the previous commit, the task definitions now can be used to get a
command that can be used to generate the toolchain locally.
Differential Revision: https://phabricator.services.mozilla.com/D167771
In bug 1811960, the change was fully reverted, but that now conflicts with
more recent changes to clang trunk. So instead, we only revert the part that
affects the writing of the profile data files.
Differential Revision: https://phabricator.services.mozilla.com/D168404
This reduces the archive size while keeping the compiler functional. This should not impact the quality of debug information of the compiled files
The size reduction is significant: from 236MB down to48MB.
Differential Revision: https://phabricator.services.mozilla.com/D167706
`mach cargo COMMAND` will run `cargo-COMMAND` using `cargo build`
arguments by default. However, it is possible to tune the arguments
using either command-line arguments, or a YAML file in `config/cargo/`.
A file `config/cargo/template.yaml` can be used to create a new
configuration for a new cargo sub-command.
Differential Revision: https://phabricator.services.mozilla.com/D166780
Using ThinLTO because it's a good compromise between performance and
compilation speed.
Activating it for both profile generation and profile usage, doing it
only for profile usage leads to a lot of mismatch, aka
function control flow change detected (hash mismatch)
which leads to profile information not beoing used.
This requires using the whole llvm toolchain (lld, llvm-ar, llvm-ranlib)
from the same revision.
This is disabled on Windows where it causes link error on the LLVM
Plugin system.
Differential Revision: https://phabricator.services.mozilla.com/D162371
Remove the mozharness copy of tooltool.py from mozilla-central.
Continue to keep a tooltool.py instance in the same path in mozharness.zip, copied from mozbuild.
Where it's simple, switch to use the mozbuild instance, but keep some mozharness tooltool.py references (when based on mozharness.zip).
Also make a minor change to mozproxy which had a bug in its mozharness-detection logic.
Differential Revision: https://phabricator.services.mozilla.com/D167223
There are no -Wtautological-constant-in-range-compare warnings in C or C++ code in mozilla-central, so we can enable this warning.
However, the -Wtautological-constant-in-range-compare flag also enables -Wtautological-value-range-compare warnings and there are some -Wtautological-value-range-compare warnings in some third-party C code.
I filed https://bugs.chromium.org/p/google-breakpad/issues/detail?id=859 for the Google Breakpad warning.
---
toolkit/crashreporter/google-breakpad/src/third_party/libdisasm/ia32_invariant.c:112:30 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value == 101 is always false
js/src/zydis/Zydis/Decoder.c:2200:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2213:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2226:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:3650:46 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value < 8 is always true
js/src/zydis/Zydis/SharedData.c:119:47 [-Wtautological-value-range-compare] result of comparison of 15-bit unsigned value != 65535 is always true
third_party/aom/aom_dsp/intrapred.c:94:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:123:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:152:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:413:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:444:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:475:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
Differential Revision: https://phabricator.services.mozilla.com/D165522
There are no -Wtautological-constant-in-range-compare warnings in C or C++ code in mozilla-central, so we can enable this warning.
However, the -Wtautological-constant-in-range-compare flag also enables -Wtautological-value-range-compare warnings and there are some -Wtautological-value-range-compare warnings in some third-party C code.
I filed https://bugs.chromium.org/p/google-breakpad/issues/detail?id=859 for the Google Breakpad warning.
---
toolkit/crashreporter/google-breakpad/src/third_party/libdisasm/ia32_invariant.c:112:30 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value == 101 is always false
js/src/zydis/Zydis/Decoder.c:2200:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2213:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2226:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:3650:46 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value < 8 is always true
js/src/zydis/Zydis/SharedData.c:119:47 [-Wtautological-value-range-compare] result of comparison of 15-bit unsigned value != 65535 is always true
third_party/aom/aom_dsp/intrapred.c:94:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:123:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:152:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:413:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:444:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:475:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
Differential Revision: https://phabricator.services.mozilla.com/D165522
This doesn't build with release branding, but allows you to create a
nightly build that has all the settings that we have on release, which
will be useful for profiling.
I could use --enable-release with a bit of effort, if you prefer
(probably renaming the current version of --enable-release to something
else).
All-in-all, suggestions welcome on this approach.
Differential Revision: https://phabricator.services.mozilla.com/D165219
