There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
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.
The existing Base64URL code converts from `const char` to `uint8_t`.
We're going to want versions that convert from character types to
character types, so make the decode routines accept generic input and
output types.
The decoding logic is the same for Base64 and Base64URL; we might as
well reuse the routines that we already have for Base64URL decoding so
we don't make mistakes in the logic.
These tables are nearly identical to the ones for base64url decoding,
but ideally will be slightly more readable, since things are broken up
into sets of eight entries at a time.
After all the previous work, we can base64 encoding nsString values
directly into nsString values, without having to go through intermediate
nsCString values. Since this routine backs base64 routines exposed to
the web, this change should help with OOMs that we see associated with
base64 encoding.
The nsACString -> nsACString encode routine has several checks in it for
correct operation, and the nsAString -> nsAString encode routine relies
on those checks happening via the nsACString -> nsACString routine.
Once we start encoding nsAStrings directly, we'll still need those
checks, and the easiest way to ensure they happen is to move the core
base64 encode logic for strings into a templated helper.
One less use of NSPR is a good thing. The failure cases that
PL_Base64Encode would have caught for us are:
1. "Truncation".
2. Integer overflow when computing destination string length.
3. Malloc failures.
The first one only gets checked if we pass in zero for the source
length, which we never do. The latter two only get checked if we pass
in a null pointer for the destination, which we never do. So removing
the error handling PL_Base64Encode implies here is a good thing.
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
The existing functions work with C strings but almost all the call sites use
Mozilla strings.
The replacement function has the following properties.
- It works with Mozilla strings, which makes it much simpler and also improves
the call sites.
- It appends to the destination string because that's what a lot of the call
sites need. For those that don't, we can just append to an empty string.
- It is declared outside the |extern "C"| section because there is no need for
it to be in that section.
Note: there is no 16-bit variant of nsAppendEscapedHTML(). This is because
there are only two places that need 16-bit variants, both rarely executed,
and so converting to and from 8-bit is good enough.
The patch also adds some testing of the new function, renaming
TestEscapeURL.cpp as TestEscape.cpp in the process, because that file is now
testing other kinds of escaping.
--HG--
rename : xpcom/tests/gtest/TestEscapeURL.cpp => xpcom/tests/gtest/TestEscape.cpp
extra : rebase_source : 51145ae2c9b0b4573c7ea0c342dcb246f9f14fb9
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
Changes ExtensionProtocolHandler to use remote streams for
moz-extension loads of file and JAR URI's to allow for
filesystem read-access sandboxing.
Adds messaging to PNecko to allow child processes to
request an input stream or file descriptor for moz-extension
URI's.
Add ExtensionProtocolHandler singleton so that NeckoParent can
call methods directly and ExtensionProtocolHandler::NewFD
can use a new member variable |mFileOpenerThread| to open files.
Adds FileDescriptorFile, a limited implementation of nsIFile
that wraps a file descriptor, to be sideloaded into
nsJARChannels so that extension JAR files can be read
using a file descriptor without accessing the filesystem
directly.
MozReview-Commit-ID: 1pcnIpjz2yR
--HG--
extra : rebase_source : 9d7334778fc81837b11b98d4e32603f7e5eb3a27
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
All the instances are converted as follows.
- nsASingleFragmentString --> nsAString
- nsASingleFragmentCString --> nsACString
--HG--
extra : rebase_source : e6a1ddc8938fecd9a735b15e872c054edf4c7910
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.
FSFindFolder is deprecated as of 10.9 and apparently continues to
work...except for the case of finding the temporary directory when the
user's home directory lives on an NFS mount (!). Using
NSTemporaryDirectory does The Right Thing here, so let's use that instead.
This patch is originally from :baku and updates the seek behaviour of
nsMulitplexInputStream. This fixes an issue with absolute seeking where if a
seek is performed and the correct offset reached, the members of the multiplex
stream were not updated to reflect this.
MozReview-Commit-ID: 7lEvuXxzYkI
--HG--
extra : rebase_source : d86a7ce0fc26abd3c9a60810bd7f7f6346e7a5b0
The lossy conversion to ASCII here can also fail; we should handle that
as well. Rewriting the code to use MakeScopeExit also avoids tangled
logic and/or duplicating calls to ensure the destination string is
truncated on failure.
clang's -Wcomma warning warns about suspicious use of the comma operator such as calling a function for side effects within an expression. Check NS_SUCCEEDED() to use HasMoreElement() in an expression and confirm that it actually returned a legitimate out parameter.
xpcom/io/nsLocalFileUnix.cpp:725:48 [-Wcomma] possible misuse of comma operator here
xpcom/io/nsLocalFileUnix.cpp:1053:39 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: aebrgc5Wqk
--HG--
extra : rebase_source : 18a2bbeb55ff106cdcb88e4889c7fd2745952a31
extra : source : e62ac5b8744d342948ab12f21f369d21f857a706
This improves performance because we won't try to fix the permissions of the file every time the nsIHandlerService implementation wants to open it, and makes it easier to access the file path from xpcshell tests.
MozReview-Commit-ID: DZmLa92qUnZ
--HG--
extra : source : bd0fdce03cc7442079e96318d3a9b519a4d403a9
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This adds a fallible version of |NS_UnescapeURL| that can be used to
gracefully handle allocation failures when the string needs to be unescaped.
MozReview-Commit-ID: 1eXPzeB2yrI
SHGetKnownFolderPath() is available on Windows Vista+ so we no longer need to GetProcAddress("SHGetKnownFolderPath"). We can set _WIN32_WINNT 0x0600 to expose the SHGetKnownFolderPath function declaration in shlobj.h and call it directly.
Also remove a redundant #include <shlobj.h>.
MozReview-Commit-ID: AoAlrfvQ5AB
--HG--
extra : rebase_source : 2fa3a0d3d122ca31fb3369a43a03b6e2c5d5dec2
When setting WINVER=0x601, we cannot compile SpecialSystemDirectory.cpp due to the following.
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(123): error C2084: function 'HRESULT SHLoadLibraryFromKnownFolder(const KNOWNFOLDERID &,DWORD,const IID &,void **)' already has a body
0:13.17 C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\shobjidl.h(32834): note: see previous definition of 'SHLoadLibraryFromKnownFolder'
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(158): error C2440: 'initializing': cannot convert from 'HRESULT (__cdecl *)(const KNOWNFOLDERID &,DWORD,const IID &,void **)' to 'HRESULT'
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(158): note: There is no context in which this conversion is possible
MozReview-Commit-ID: 2KZEzcn21S7
--HG--
extra : rebase_source : b13f2fb11c9e006a83c7d5c3175af001e384b55e
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
This keeps the ITEMIDLIST pointers in the "LP" flavour to avoid casting away __unaligned qualifiers. __unaligned is meaningless on non-Itanium platforms but clang-cl nonetheless has trouble with it. (https://llvm.org/bugs/show_bug.cgi?id=30578)
This actually accomplishes what was discussed in the bug and marks any file with the
relevant URI flags as WebDownload, and everything else as OtherDownload.
Note that I'm using DoGetProtocolFlags in order to deal with
nsIProtocolHandlerWithDynamicFlags correctly; while just getting protocol flags
from the IO service directly would be less work, it's technically less correct.
MozReview-Commit-ID: HgD1fV98IEc
--HG--
extra : rebase_source : f114532b48dbca5c83871e61c8d04c719e3b38d1
kLSItemQuarantineProperties was deprecated in 10.10. AFAICT it was replaced by
kCFURLQuarantinePropertiesKey, which was inconveniently new in 10.10.
On my 10.11 machine, the Info.plist fix from the previous patch was not
sufficient to get the data to actually show up when using the old (deprecated)
key. I suspect the setter is a no-op with the old key. So here's code that
uses the new key ("documented" in LSQuarantine.h, where conveniently
the actual properties in the dictionary have kept their keys, but the
dictionary key is now referenced as the CF one).
MozReview-Commit-ID: IMsV6TLrYTP
--HG--
extra : rebase_source : 400db5d7dcbc8fbf165c9e8049376d50001e8f1c
The patch also changes RemoteOpenFileChild::OpenNSPRFileDesc() so that it
cannot succeed with a null fd, so that checking just the return value is
sufficient.
--HG--
extra : rebase_source : cc40bbcf2a9991edc9d3da3fb624d27db50b4996
The patch also makes GetInputStream() fail if the pipe isn't initialized, just
like GetOutputStream().
--HG--
extra : rebase_source : 7391b331ffe25e0ac7ebc755f7da313dc7b5517d
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
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
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
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
ConvertStringLineBreaks calls ConvertUnicharLineBreaksInSitu which uses
fallible allocation. We should make the potential allocation in |BeginWriting|
fallible as well and handle the failure. This also updates the callers to
|ConvertStringLineBreaks| to handle the error properly in release builds.
aOutputLeft is null checked and then dereferenced twice more in this function,
and all callers pass a non-null pointer. So just remove the null check.
--HG--
extra : rebase_source : 8190a51fde8434ac346a4e23db5ed4703762778c
ConvertStringLineBreaks calls ConvertUnicharLineBreaksInSitu which uses
fallible allocation. We should make the potential allocation in |BeginWriting|
fallible as well and handle the failure. This also updates the callers to
|ConvertStringLineBreaks| to handle the error properly in release builds.
This will be used in bug 1273711 to avoid an OOM.
This also tweaks one of the existing overloadings of Base64Encode to return
NS_ERROR_OUT_OF_MEMORY on OOM instead of NS_ERROR_INVALID_ARG.
--HG--
extra : rebase_source : a2ad472b11ac2c858487bf5fdae84d183084773b
The argument naming in Base64.{h,cpp} is horribly confused, with a lot of them
gotten backwards. This patch fixes that, and also introduces a more consistent
naming scheme for arguments and local variables: "binary" is used for binary
data, and "base64" is used for base64-encoded data.
This patch doesn't change any functionality.
--HG--
extra : rebase_source : 7d8a08762e291851bd117a0409fc8715b830fdbe
This is as much a perf issue as it is a UX issue. We should be passing a HWND to
ShellExecuteEx because it can show UI, and that UI should have a proper
parent-child relationship with the Mozilla window. We should do that on the
main thread because of the GUI stuff. OTOH, we want the ShellExecuteEx call to
be a lightweight as possible, hence the SEE_MASK_ASYNCOK flag.
MozReview-Commit-ID: 7VLkWTRWPoe
--HG--
extra : rebase_source : ce16bc0c926a299d9b9103ad0697e3cd07b9157d
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: 9AkkAUDMln6
--HG--
extra : rebase_source : 76126361de678729344b0e9eaeac1d523f88ebb4
service. This is needed so that chrome processes know where sandboxed content
processes will be writing their temp files, and so that content processes know
where to write; r?bsmedberg
MozReview-Commit-ID: BK9bTxFGvZO
--HG--
extra : rebase_source : dec290c82fb934ceadc0c9ce0cf87337aa1e8f47
Nothing in mozilla-central uses the NS_APP_BOOKMARKS_50_FILE/BMarks key except
tests. It's also not been very useful since the switch to places in ... Firefox
3? so even if addons use it, it's not doing them much good.
BookmarkHTMLUtils.defaultPath returns the same thing anyways for those that
really do insist on getting the equivalent thing (but I'd argue
BookmarkHTMLUtils.defaultPath, as well as the browser.bookmarks.file pref could
just go away as well).
Seamonkey does use NS_APP_BOOKMARKS_50_FILE/BMarks, but they really only need
the #define, which they can add in their source.
Nothing apart the code that was just removed uses those keys, so remove them.
Actually, there is a use in Seamonkey, but considering they're shipping with
omnijar, the code expecting the directory has not been working as designed for
a while, so they can fixup and remove that use as well.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
The distinction between moz_malloc/moz_free and malloc/free is not
interesting. We are inconsistent in our use of one or the other, and
I wouldn't be surprised if we are mixing them anyways.
Nicholas Nethercote
Kris Maglione
Chris Pearce
Sebastian Hengst
Andrea Marchesini
Mike Hommey
Jean-Yves Avenard
Boris Zbarsky
Nomis101
Ben Kelly
Eric Rahm
Tom Ritter
Ryan VanderMeulen
Nathan Froyd
Michael Kaply
Valentin Gosu
Masatoshi Kimura
Haik Aftandilian
Brad Werth
Sylvestre Ledru
Mats Palmgren
Carsten "Tomcat" Book
Bill McCloskey
Wes Kocher
Henri Sivonen
Ehsan Akhgari
Colin Dean
Bryce Van Dyk
Paolo Amadini
Patrick McManus
Phil Ringnalda
Chris Peterson
David Major
Iris Hsiao
Tom Tromey
Michał Górny
Randell Jesup
Cervantes Yu
Makoto Kato
Tomislav Jurin
Bob Owen
Andi-Bogdan Postelnicu
Gerald Squelart
Gijs Kruitbosch
Tom Schuster
Josh Matthews
Honza Bambas
Josh Aas
Jarda Snajdr
Simon Lindholm
Wei-Cheng Pan
Jim Chen
Andrew McCreight
Kyle Huey
Ralph Giles
Aaron Klotz
Kit Cambridge
Stone Shih
Gregory Szorc
Wilmer Paulino
Jeff Lu
Julian Seward
Birunthan Mohanathas
David Rajchenbach-Teller
Lars T Hansen
Florian Quèze
Michael Layzell
Arnaud Bienner
Bobby Holley
Robert O'Callahan
Juan Gomez
Ted Mielczarek
Nikhil Marathe
Felix Janda
Neil Rashbrook
Kartikaya Gupta
Titi_Alone
Jed Davis
Trevor Saunders
Jacek Caban