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
(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
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
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 : f7faa6f22ffc56fb4da7ae96eb571a35fa6f615d
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 : 519980829be4ff4a0941c0e8d18be5761ece6552
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
--HG--
extra : rebase_source : 5de1e9335895d65e6db06c510e8887d27be3390f
extra : source : f762f605dd83fc6331161a33e1ef5d54cafbd08d
ISO C++ forbids converting a string constant to 'wchar_t*' [-Werror=write-strings]
Either change it to a nullptr (which has same intent) or pass through a static
MozReview-Commit-ID: CSunOCyO9PN
--HG--
extra : rebase_source : bfdabc1f463eca75987c6561f7c3ea60acf0340f
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
After all the previous work, we can now base64 decode nsString types
without intermediate conversion steps to nsCString, which is faster and
more memory-efficient.
The current nsString decoding routine indirectly relies on the various
checks this routine performs; making it generic over string types
ensures that we can eventually call it directly from the nsString
decoding routine.