The layout module initializes a bunch of things, specifically
XPConnect. And if we're not loading chrome manifests, we shouldn't need
to initialize the layout module.
Checking that the current process type is not equal to some value
requires adding code when new process types are added. Since it seems
reasonable to assume that all new process types aren't going to require
chrome manifests, let's make the code reflect that assumption as well,
and reduce the number of places you need to touch when adding a new
process type.
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
nsLayoutModule must be initialized in order to call into JS, but I
don't want to have to rely on calling a service in that
module. Instead, always initialize the module very early in component
manager initialization. This also makes initialization more
consistent, so things like errors in manifests won't affect when it
happens, which can result in different behavior in different builds.
I also made nsLayoutModule initialization infallible, because I can't
imagine that we can do much that is useful without it.
Another change I made is that gInitialized is set to true even in a
GPU process. This simplifies checking whether initialization has
happened already when we start up the layout module.
Differential Revision: https://phabricator.services.mozilla.com/D9583
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
clang can handle MSVC-like codepaths generally, so we want to use those
when building with clang for Windows. So we switch _MSC_VER over to _WIN32
to pick up those codepaths when compiling for Windows with clang.
Additionally, we relax the ordering of sections for the same scenario.
Note that we do need to tell clang to use -fms-extensions with the MSVC code,
we do that in the mingw clang build job patch.
Differential Revision: https://phabricator.services.mozilla.com/D3526
--HG--
extra : moz-landing-system : lando
Nearly all of the consumers of category enumerators require the entry value,
either along with or instead of the name. Including both by default simplifies
things considerably for most consumers, and allows us to remove the XPCOMUtils
wrapper that JS callers typically use to enumerate category entries.
Differential Revision: https://phabricator.services.mozilla.com/D4277
--HG--
extra : rebase_source : 1efe0434e150f08bb9f4d8a4c6f6e993efebf8d8
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
This assertion was always meant to be a best-effort thing to catch obvious
errors, but the cases where the assumptions it makes fail have been growing. I
could remove it entirely, but I'd be happier keeping at least some basic
sanity checks.
This compromise continues allowing any address below the first argument
pointer, and extends the assertion to also allow anything more than 2KiB above
it. We could probably get away with stretching that to at least 4KiB, but 2
seems safer, and likely enough to catch the obvious cases.
Differential Revision: https://phabricator.services.mozilla.com/D3542
--HG--
extra : source : a5f51c76930c49160bf5e909301d8e7f1a83e379
extra : amend_source : e3decc44bfb4bed6696a394980c378dc033e1021
This assertion was always meant to be a best-effort thing to catch obvious
errors, but the cases where the assumptions it makes fail have been growing. I
could remove it entirely, but I'd be happier keeping at least some basic
sanity checks.
This compromise continues allowing any address below the first argument
pointer, and extends the assertion to also allow anything more than 2KiB above
it. We could probably get away with stretching that to at least 4KiB, but 2
seems safer, and likely enough to catch the obvious cases.
Differential Revision: https://phabricator.services.mozilla.com/D3542
--HG--
extra : rebase_source : 9e17aa3d751f75deff67e40d223fda7aaa4f84f0
extra : amend_source : 86ada4dd01584defeaa5dcb093ad9a73b34f0318
For all intents and purposes, this is now the same as the 'ischrome' flag.
MozReview-Commit-ID: 4z4SDs5M8zU
--HG--
extra : source : 2a5aa9de1fd9760a9245ecae815a6e02bb9eef42
This is unused now that binary component support has been removed.
MozReview-Commit-ID: KHTsF4sSoZX
--HG--
extra : source : 20a1a11b4d0ba7010b36b952bb212f3c36e6aac3
This serves no purpose now that legacy theme support has been removed.
MozReview-Commit-ID: BpLcQYfZtAZ
--HG--
extra : source : ca43bd11f43161f03d3e0dd6bd9b28d446bbe7e1
For all intents and purposes, this is now the same as the 'ischrome' flag.
MozReview-Commit-ID: 4z4SDs5M8zU
--HG--
extra : rebase_source : 7f6bd7e7ea9457920338439cfbe0ce2c191b4075
This is unused now that binary component support has been removed.
MozReview-Commit-ID: KHTsF4sSoZX
--HG--
extra : rebase_source : 97a12aadbb4b726785b3bc565ac34854e6c04d8e
This serves no purpose now that legacy theme support has been removed.
MozReview-Commit-ID: BpLcQYfZtAZ
--HG--
extra : rebase_source : fe8e19517d12084631e3756a4a803fd6d3c4fc39
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : source : 5fb0b7746a5d56563b471e3061ccca124ea45485
extra : absorb_source : 275f5d4dc2c02e3d0391ed16e8690dac1e601758
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : source : 8359f8fe418419c50ab0ed93496e7445b570ba9f
extra : absorb_source : 2a33ae4e7e6d312adcea8ece2158f07a7050e01e
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : rebase_source : 8d41a3fc5bc1ffe88af998bf9a0ba9ac3331a085
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : rebase_source : 57d151df64e29ee756f290e7eb047610b567ef04
The following was removed:
- the main meat of the overlays and interface in XULDocument
- all overlay observers and forward references
- the notion of a master document
- XUL overlay provider
- manifest parsing of overlay attribute
- references to "overlay" atom
- restrictions on persistence (only need because of overlays)
- unused code that the above referenced
I also attempted to update comments that referenced overlays, but there is still
some work to be done here.
MozReview-Commit-ID: 8lrirzcgSuJ
--HG--
extra : rebase_source : 25b4e1d3fb2af6f02d894887271fd345c9c2083b
The sStaticModules list is, practically speaking, a copy of the list
of components we already have in libxul, augmented at runtime with
a few other components for tests (for gtest and xpcshell). We don't
actually need to keep that copy in memory. We can instead just use the
pointers in libxul directly to register them to the component manager,
and use a separate list, only for those extra components when they need
to be registered.
--HG--
extra : rebase_source : 1a32c95312d8577c99823adea8dbc0b022c286b2
Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.
--HG--
extra : rebase_source : de968c61dc4ef337fdc28745c202334ac41763cd
Style overlays are no longer used outside of tests.
MozReview-Commit-ID: 798Id5JITAm
--HG--
extra : rebase_source : edfbfc973f865d72bbc019a26519436157476793
Unfortunately, I wasn't able to figure out a way to make firefox build & run in
the intermediate stages of these commits. Because of this, I am going to just
delete most of the code which I am deleting in the first patch, as I figure that
those are somewhat uninteresting changes, and then make the other changes in the
following patches.
In total, the following things are deleted:
1. All of xpcom/typelib, except for `xpt/tools` - this directory is being
subsumed entirely into xpcom/reflect/xptinfo.
2. Most of the code in xpcom/reflect/xptinfo, it is being rewritten to avoid
allocating and contain all of the necessary data structures.
3. idl-parser's typelib.py XPT generator, as it will be replaced.
4. Most includes of files which have been deleted.
NOTE: xpcom/typelib/xpt/tools/xpt.py was not removed, as it is used by bundling
code & bundling tests, which we don't want to remove yet.
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : 6512a05f2a8bee1e6e6b0423d2cb376d8c34728b
This patch removes C++ code related to reading in XPT information from
files. (Code related to packaging XPT files will be removed in the
next patch.) This includes code in the manifest parser, in addition to
the actual code for parsing files.
XPT information is now loaded directly from a single static data
structure, XPTHeader::kHeader, which will be automatically generated
at compile time from .idl files (via .xpt files). Note that the script
to do that is not added until part 6 of this patch series, so linking
will fail on parts 2 through 5.
I inlined XPTInterfaceInfoManager::RegisterXPTHeader into the ctor,
because that is the only caller. It feels like the lock there should
not be needed any more, but I left it alone for now.
The forward declaration of XPTArena in xptiprivate.h is needed because
it was being bootlegged via xpt_xdr.h. Some of the data structures in
reflect/xptinfo/ (which wrap the xpt_struct.h data structures) are
still allocated using XPTArena. Hopefully we can get rid of that in
followup work.
I also deleted a lot of comments in xpt_struct.h that talk about the
on-disk format. I also deleted checking of the major version number,
because that should not matter when the XPT information is baked into
the executable.
MozReview-Commit-ID: 6NJdaCWRBhU
--HG--
extra : rebase_source : e169b827a64bad5dde15de6be0b2ff5e7aa35e3f
This undoes the parts of bug 977026 related to manifest parsing that
are still around.
MozReview-Commit-ID: CimJNEl8KKk
--HG--
extra : rebase_source : 7e84ff5e5a4adda66ff35044b7a873d7137e3417
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is null checked. The patch uses IsVoid() to replace
the null checks (and get() and EqualsLiteral() calls to replace any implicit
conversions).
--HG--
extra : rebase_source : 484ad42a7816b34b86afbe072e04ba131c1619c6
I went with the simplest possible approach here, and only added support for
"locale" and "override" entries, since we don't expect this to stick around
very long.
MozReview-Commit-ID: IDQ86s3jgnu
--HG--
extra : rebase_source : 32cfcfad667d2cb82be6acd1e0a42ca1854b7691
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
Manifest entries can contain flags, one of which allows to match on the
os running Gecko. The match is performed against the value returned by
nsIXULRuntime.getOS, which itself comes from the build-system's
OS_TARGET.
In practice, this means that things like os=WINNT, os=Darwin,
os=Android, os=Linux are valid filters, but the latter is too specific,
and most of the time, one would want something that is "any OS but
WINNT, Darwin, Android", which can't be expressed with manifest entry
flags (there is no "and" for them, only "or").
For convenience, we add the keyword "LikeUnix", which has that meaning.
--HG--
extra : rebase_source : faf3986d2a4361d12a512752e15e81270be224ef
Manifest entries can contain flags, one of which allows to match on the
os running Gecko. The match is performed against the value returned by
nsIXULRuntime.getOS, which itself comes from the build-system's
OS_TARGET.
In practice, this means that things like os=WINNT, os=Darwin,
os=Android, os=Linux are valid filters, but the latter is too specific,
and most of the time, one would want something that is "any OS but
WINNT, Darwin, Android", which can't be expressed with manifest entry
flags (there is no "and" for them, only "or").
For convenience, we add the keyword "LikeUnix", which has that meaning.
--HG--
extra : rebase_source : ce2549fab96cb1df3f984e43cb08413cad49479e
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
The build fails with:
/usr/bin/ld: ../../xpcom/components/nsComponentManager.o: relocation R_386_GOTOFF against protected data `start_kPStaticModules_NSModule' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
This is a patch from 2016/04/27 16:36:50 ryoon found on
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/firefox45/patches/#dirlist.
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
This patch adds an assertion that makes sure that the nsCategoryManager is
destroyed after the nsMemoryReporterManager, because bad things would happen
otherwise.
Also, nsCategoryManager uses manual memory management (it's AddRef/Release are
hardwired to always return 2 and 1 respectively) so it doesn't matter if we
register it as a strong or weak memory reporter. But it's more common to use
RegisterWeakMemoryReporter when the argument is |this|, so this patch does
that.
--HG--
extra : rebase_source : 4ca33404d4c6f2b271e1ad008ea1a9a79f3ef666
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Having the Impl suffix isn't really necessary, and if we start creating
instances of these classes directly, it's also rather ugly. Let's get
rid of them.
Ehsan Akhgari
Dragana Damjanovic
Nathan Froyd
ffxbld
Sylvestre Ledru
Michael Froman
Bogdan Tara
Dorel Luca
Daosheng Mu
arno renevier
Andrew McCreight
Kris Maglione
Tom Ritter
shindli
Cosmin Sabou
Brindusan Cristian
Brian Hackett
Brendan Dahl
Mike Hommey
Peter Van der Beken
arthur.iakab
Chris Peterson
Nika Layzell
Andrea Marchesini
Simon Fraser
Ryan VanderMeulen
Masatoshi Kimura
Nicholas Nethercote
Chung-Sheng Fu
Sebastian Hengst
Michael Kaply
Eric Rahm
Mats Palmgren
Wes Kocher
Tom Tromey
Bill McCloskey
David Anderson
Benjamin Smedberg
Andi-Bogdan Postelnicu
Iris Hsiao
J. Brown
Michael Layzell
Gregory Moore
Alexandre Lissy
Carsten "Tomcat" Book
Jim Chen
Kyle Huey
Nathan Froyd
Jacek Caban