Doing this means that instantiations of nsRefPtr<T> won't require
nsCOMPtr_helper::operator() to be defined. Only actual uses of the
overloads will require the definition.
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.
The interesting feature JSONWriteFunc has, contrary to JSONWriter, is that it
only has virtual methods, which makes it a better candidate to be passed
around between libraries not linked against each other.
This will allow to make dmd and libxul independent from each other.
This patch does the following.
- Moves the logic for computing the ideal capacity for a SegmentedArray out of
SnowWhiteKiller into its own class, SegmentedArrayCapacity.
- Replaces the nsTArray in CollectWhite(), which can be very large and is
complicit in ~1% of OOM crashes, with a SegmentedArray.
--HG--
extra : rebase_source : 732743311a08fcc3dfe43a1b308846b93d30e6ed
This patch generalizes SegmentedArray a little, and then uses it instead of
nsTArray in SnowWhiteKiller. This avoids some large (sometimes 1 MiB or more)
allocations which were usually mostly unused.
This adds "hasSeccompBPF" for seccomp-bpf support; other "has" keys
will be added in the future (e.g., user namespaces).
This also adds "canSandboxContent" and "canSandboxMedia", which are
absent if the corresponding type of sandboxing isn't enabled at build
type (or is disabled with environment variables), and otherwise present
as a boolean indicating whether that type of sandboxing is supported.
Currently this is always the same as hasSeccompBPF, but that could change
in the future.
Some changes have been made to the "mozilla/Sandbox.h" interface to
support this; the idea is that the MOZ_DISABLE_*_SANDBOX environment
variables should be equivalent to disabling MOZ_*_SANDBOX at build time.
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.
