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
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time. If we're
reusing the timer, we also don't need to repeatedly set the timer's
target: we can set the target once at timer creation, and then be done.
We can do this safely here because mTaskCategory doesn't change
throughout the life of the IdleTaskRunner; we make mTaskCategory `const`
to make this more explicit to the reader.
There is no advantage in making these methods more restrictive on their
parameters than AssignLiteral.
The current implementation of the AppendLiteral overloads for equivalent
char_types is more permissive than AssignLiteral, but comments in the
implementation mention the possible optimization used in AssignLiteral and so
are assuming a similar constant and static storage duration restriction on its
parameter. The optimization may never be implemented, but clients that would
benefit from support for non-constant or non-static parameters are also
expected to be rare, so there is little value in ruling out the optimization
at this stage.
ReplaceLiteral currently uses the AssignLiteral optimization.
Differential Revision: https://phabricator.services.mozilla.com/D8777
--HG--
extra : moz-landing-system : lando
A character array initialized with a list of character literals will not
necessarily have a trailing null-terminator required for AssignLiteral or
trimmed in EqualsLiteral.
Depends on D8775
Differential Revision: https://phabricator.services.mozilla.com/D8951
--HG--
extra : moz-landing-system : lando
"Bound" is the term used in the C++ standard to describe the number of
elements in an array.
EqualsLiteral has no opportunity to optimize for constant and static storage
duration parameters.
Depends on D8773
Differential Revision: https://phabricator.services.mozilla.com/D8774
--HG--
extra : moz-landing-system : lando
There is no advantage in AssignASCII() for char, and AssignASCII() does not
exist for char16_t array and char_type. Similarly for ReplaceASCII and
AppendASCII. This AssignLiteral() overload already says it is not only for
ASCII.
Depends on D8771
Differential Revision: https://phabricator.services.mozilla.com/D8773
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR. Change APP_PATH to be the path to the parent process .app directory and make GetAppPath return this path when called from the parent or a child process.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Since https://hg.mozilla.org/mozilla-central/rev/9db7cf4cc385#l13.44 the type
system always excludes calls with character pointers and so there is no need
to mention this in the comment.
The comment for the 8-bit to 16-bit AssignLiteral overload is modified a
little to use "char" instead of "character" so as not to imply that anything
other than 8-bit char parameters may be provided to that overload.
The ReplaceLiteral and InsertLiteral comments are adjusted to use "character"
instead of "char" so as not to imply that the method or comment is limited to
8-bit char parameters.
Differential Revision: https://phabricator.services.mozilla.com/D8770
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
The NS_NewTimer* family of functions, when using a custom event target,
currently go through a path that looks something like:
auto timer = createTimer()
timer->SetTarget(target);
// call the requisite Init* function
return timer;
This setup is inefficient, because SetTarget requires the timer mutex to
be acquired. The mutex acquisition here is completely unnecessary,
because the timer hasn't yet been shared out to the wider world; we can
set the timer target without acquiring the mutex at all because we know
that no sharing is possible at this point.
This patch reworks things somewhat to make that possible.
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
Sometimes the protocol buffer data (RiceEncodingData) sent by Google's Safe Browsing server has the following properties:
1. |has_first_value| is false
2. |num_entries| > 0
In this case, we can still parse the data and apply partial update correctly by assuming that the first value is equal to 0.
Differential Revision: https://phabricator.services.mozilla.com/D6393
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
The creation of a new index or an object store may trigger a
ConstraintError if any of those elements already exists. Unfortunately,
the information provided by the ConstraintError is not enough to
determine the conditions that triggered the error.
This patch overrides the generic ConstraintError message with more
specific information about the duplicated index or object store.
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
--HG--
extra : rebase_source : b68dd7c73f5036dcd6be4c3700b757441f59f9f2
This is the same as the other patch, except that it is applied to the
case where the QI returns an nsresult.
In addition, I marked the WithError helper class as being stack-only.
Depends on D7553
Differential Revision: https://phabricator.services.mozilla.com/D7554
--HG--
extra : moz-landing-system : lando
This patch adds a static assert to enforce that do_QueryInterface is
not used to go from a class to a base class, because that can be done
more efficiently via a static_cast. This is done by putting the type
of the source into the nsQueryInterface type. Once that is done, it is
easy to check the source and destination type. This has to be done
carefully so that in non-DEBUG builds, where NSCAP_FEATURE_USE_BASE is
defined, we don't generate any additional code.
The first step is to rename nsQueryInterface to
nsQueryInterfaceISupports. In DEBUG builds, I then add a new subtype
nsQueryInterface<T>, where T is the type of the object we are going to
QI. This class is a thin wrapper around nsQueryInterfaceISupports that
only forwards operations to the base class.
The main bit of trickery here is PointedToType<T>, which is needed to
get the type parameter for nsQueryInterface. This dereferences the
type, gets the address of it, then does RemovePointer. This is needed
because a wide variety of pointer types are passed in to
do_QueryInterface, including RefPtr<>, nsCOMPtr<>, raw pointers, and
OwningNonNull<>. PointedToType<RefPtr<T>> is equal to T,
PointedToType<T*> is equal to T, and so on.
In NSCAP_FEATURE_USE_BASE builds (opt), we only use
nsQueryInterfaceISupports, but in debug builds we use
nsQueryInterface<> where possible. The latter is also used for the
nsCOMPtr<nsISupports> overload, because we can always QI to
nsISupports, because that is sometimes used for canonicalization.
Another gross bit is that Assert_NoQueryNeeded can no longer use
nsCOMPtr<>, because it works by QIing T to T, which is banned by the
static analysis. Instead I had to reimplement it by hand.
Depends on D7527
Differential Revision: https://phabricator.services.mozilla.com/D7553
--HG--
extra : moz-landing-system : lando
This saves one word per static atom, per process.
The `nsGkAtoms` change is only a small part of this commit.
In regen_atoms.py:
- There is now only one link name per platform: nsGkAtoms::sAtoms[].
- But there is a new constant per atom, giving the index into
nsGkAtoms::sAtoms[].
- And the `atom!` macro for each atom indexes into nsGkAtoms::sAtoms[] using
the index constant.
- A couple of `*mut` pointers are now `*const`.
Elsewhere, the `(nsStaticAtom*)` casts within the `AppendElement()` calls are
necessary to avoid link errors, presumably due to some template instantiation
wrinkle.
--HG--
extra : rebase_source : 629642e708c8bc6e27d6057beae5f35955fdd837
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
In TestEventTargetQI.cpp, nsIThreadPool is a subclass of
nsIEventTarget, so we cannot QI from the former to the latter once
trivial QIs are banned. However, we still want to check if a QI to
nsIEventTarget does something, so I added an intermediate cast up to
nsISupports, and then QI from there. I wrapped that all up in a
templated function, because the code is a bit ugly, and used it
everywhere for uniformity, even though it is not always needed.
I fixed TestCOMPtr.cpp in the same way, by casting up to nsISupports.
Differential Revision: https://phabricator.services.mozilla.com/D6855
--HG--
extra : moz-landing-system : lando
This doesn't fix the problem, but at least moves the resulting assertion
closer to the problematic caller, and makes it easier to diagnose.
Differential Revision: https://phabricator.services.mozilla.com/D7042
--HG--
extra : rebase_source : 4a016d1dce77a269b886467c9343dab125079a8f
extra : amend_source : 4e9133e70932f382e0b5df9e487978b95d05781b
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
extra : intermediate-source : 89a0c0874d400dd324df6fc3627c0c47d130df19
extra : histedit_source : bbd7900e3d754bde925a411c10aa30a1d6e22edd
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : rebase_source : 897e2d32d1dfee24d51459065925fb9b41fa543a
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : rebase_source : 88c56fa4f5da97f33ade08d892c3d8c42666307e
