Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
nsEscape.cpp doesn't build in non-unified mode, as it uses mozilla::fallible,
mozilla::CheckedInt and mozilla::ASCIIMask::IsMasked without prefixing them
with the mozilla namespace. I suspect this file is usually included in
unified_cpp file which includes a "using namespace mozilla" directive.
MozReview-Commit-ID: GwlsK8kytLj
--HG--
extra : rebase_source : c3063aff7cdf10c416b8ee782c9bee745e643842
We were using a StaticRefPtr without it being fully defined for
SystemGroupImpl::sSingleton, resulting in a non-unified build failure.
MozReview-Commit-ID: AgSuVvGTri7
--HG--
extra : rebase_source : 906e30e8c2c21e13a045a941e9d92e1d2d2af079
This Makefile.in contains a bunch of cruft for Tier-3 platforms. If
someone is still supporting any of them they can make the necessary
fixes to moz.build files themselves.
MozReview-Commit-ID: HxbbCv395Y5
--HG--
extra : rebase_source : 94f04128d2b3dd1285dfeafbfeb320b2f0d0bb19
extra : histedit_source : 2353127161ae58e54b6296e98b6b4b972ae439fe
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Adds a new directory provider key "XRESysExtDev" to be used by system extension
developers needing to load system extensions from a directory readable by
sandboxed content processes.
MozReview-Commit-ID: 4BKOZoPzCC3
--HG--
extra : rebase_source : 452db8d53a1f0248a080f858c48492978b5db808
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
