Forward declaring functions with default arguments is difficult. If you try to say:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags);
and then later have:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags = 0);
{
...
}
the compiler complains that default arguments cannot be added to a
function template that has already been declared. If you attempt to
mollify the compiler by declaring instead:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags = 0);
the compiler then complains about redefining the default argument (!)
when an actual definition is found.
To circumvent this, manually implement "default" arguments by providing
a three-argument form of CycleCollectionNoteChild, which simply forwards
to the four-argument version.
We build without UNICODE, so we end up calling the ANSI version
of the function, and then we would attempt to interpret the
resulting narrow char buffer as a wide char buffer.
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.
In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).
On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.
Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.
To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.
The new MOZ_ASSERT_CLASSNAME check in MOZ_COUNT_CTOR and friends
fails under gcc 4.4 on the B2G ICS emulator build, because
nsGonkCameraControl calls the COUNT macros from a local class.
This wasn't allowed in C++03, but that was changed in C++11, and
our more recent toolchains either don't reject the code or don't
encounter such a nested class name.
I picked gcc 4.7 as the minimum version because that's the version
used by the B2G JB Emulator build, which works. There's no restriction
on clang or msvc version.
