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
Mike Hommey
Mark Banner
Masayuki Nakano
serge-sans-paille
Matthew Gregan
Narcis Beleuzu
Arthur Carcano
Cosmin Sabou
Andi-Bogdan Postelnicu
Stanca Serban
Julien Cristau
Nicolas Chevobbe
Marian-Vasile Laza
Cristina Horotan
Noemi Erli
Kershaw Chang
Norisz Fay
Ben Hearsum