The earlier patches in this bug were written before we had
sophisticated binding generation so the types didn't match very well.
This fixes all of that.
MozReview-Commit-ID: DpcblpB8vxW
These tests were failing because of some misoptimizations that GCC did.
clang is generating correct code here, and the tests correctly pass, so
we can mark them as such.
NDK r15+ clang changed the code generation strategy for the __atomic_*
intrinics such that using them with 64-bit types now requires linking
with libatomic. Our current configure tests for libatomic doesn't catch
this, because the std::atomic implementation is such that it doesn't
require an external library, even for 64-bit types, whereas the
__atomic_* intrinsics do. The safest thing to do is to force this
configure check to always return true when we are compiling for
x86/Android with clang.
The NDK clang needs to be informed about the existence of a GCC
toolchain, so important programs like the linker can be located. With
this change, we're starting to use command-line options that are
incompatible with GCC, so we also add a check to inform the user about
the non-support for this configuration.
Our normal method of locating the compilers in the NDK is to set
--with-toolchain-prefix when compiling for Android. However, the clang
binaries are in a different location than would otherwise be implied by
--with-toolchain-prefix. Additionally, we still need to know about
--with-toolchain-prefix because the NDK clang needs to be pointed there
so clang can find important binaries like the linker and because various
other bits of the build system depend on the --with-toolchain-prefix
value as well.
So we need a separate mechanism for communicating the whereabouts of the
NDK clang. We can't set CC and CXX because doing so would conflict with
the CC and CXX values exported to the js/src/ subconfigure. But Android
already has an extra_toolchain_flags function that we use for informing
moz.configure about additional flags needed solely for Android, and we
can use a similar trick to communicate the existence of the NDK's clang
to the main C/C++ compiler selection process.
We already dealt with issues around dlsym not resolving weak symbols
with libc in bug 1081034. This fix applies the same workaround to libm,
which solves the isnanf issue.
The previous fix for looking up __isnanf is no longer needed.
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
Tom Schuster
Sebastian Hengst
Jorg K
Nathan Froyd
Jeff Muizelaar
Boris Chiou
ffxbld
Phil Ringnalda
Joel Maher
Nihanth Subramanya
Jonathan Kew
Kartikaya Gupta
Andrea Marchesini
Mark Banner
ZER0