xptcstubs_arm mostly works on iOS but Apple's assembler is ridiculous so
the inline assembly for the SharedStub and the stub methods needs judicious
preprocessor use.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
After this change, we have ShallowSizeOf{In,Ex}cludingThis(), which don't do
anything to measure children. (They can be combined with iteration to measure
children.)
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Adding isMainProcessScriptable() into the middle of nsIInterfaceInfo
caused problems with some binary addons that relied on the ordering of
the methods in nsIInterfaceInfo. In an attempt to placate those addons,
move isMainProcessScriptable() to the end of the vtable. This change is
a no-op for normal libxul usage.
Constructing kComponentsInterfaceShimMap required a static constructor
on some compilers, due to a non-constexpr constructor and the necessity
of copying non-constexpr things like nsIID. This static constructor is
large (several kilobytes of object code on x86-64) and completely
unnecessary.
To fix this, let's add a constexpr (well, MOZ_CONSTEXPR) constructor to
ComponentsInterfaceShimEntry. This change alone doesn't completely
solve our problem, because the nsIID member still needs to be copied.
But doing that copying is silly: we only use the IID for constructing a
ShimInterfaceInfo in ShimInterfaceInfo::MaybeConstruct, and the
ShimInterfaceInfo constructor takes a const reference. So let's store a
const reference in ComponentsInterfaceShimEntry, too, and make that
structure significantly smaller in the process.
As explained in bug 1111355, having avx enabled appears to change the
alignment behavior of alloca (apparently adding an extra 16 bytes) of
padding/alignment (and using 32-byte alignment instead of 16-byte). The
suggestion of using __bultin_alloca_with_align in bug 1111355 didn't fix
the problem, so this seems to be the best available workaround, given
that this code, which should perhaps better be written in assembly, is
written in C++.
Interestingly, this is NOT fixed by #pragma GCC target ("arch=x86-64").
(I determined the (undocumented) name for the default -march value on
x86_64 from the gcc source code (gcc/config/i386/i386.c, function
ix86_option_override_internal, code that sets opts->x_ix86_arch_string .)
I confirmed that this sets the same macros based on the empty diff
between the output of 'gcc -E -dM -x c++ /dev/null' and 'gcc -E -dM -x
c++ -march=x86-64 /dev/null', which was not an empty diff for other
-march values (e.g., k8).)
I confirmed that the push_options and pop_options actually work by
putting the push/pop pair around a different (earlier) function, and
testing that this did not fix the bug (with the pop_options before
NS_InvokeByIndex).
See the gcc documentation at:
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Specific-Option-Pragmas.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Attributes.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/i386-and-x86-64-Options.html
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This fixes the download panel issue, and brings us revs 727721e5d8ac,
844b142d8111 and 236989b3a807 as a bonus. Remove the unmaintained
OpenBSD/amd64 specific versions.
