Instead of lvalues, MozPromiseHolder::Resolve and Reject now take either
const& or && values of the expected types, to allow move semantics all the way
to the ResolveOrRejectValue object.
Note that we won't just take forwarding references of any type, as this could
lead to implicit conversions by bypassing the 'explicit' marker of the value
type constructors, like in bug 1331137.
MozReview-Commit-ID: K0jeY6WTXI1
--HG--
extra : rebase_source : 7ee0fd1edfdeadb239f48c8b5b46fd54af3ec5d2
MozPromise::All sets up 'Then' lambdas on all sub-promises, each one taking the
resolve/reject object by value.
Since this value will not be used again in the lambda, it is safe to Move it,
and from there MozPromiseHolder::Resolve/Reject can also Move it again into the
holder storage, potentially saving two copies per Resolve/Reject.
Also, once all sub-promises have been resolved, the resolve-values can be
Move'd into the joining promise's Resolve function.
MozReview-Commit-ID: 5oxgNEnE5lq
--HG--
extra : rebase_source : f0542055beb1434e7db384722c5123d888ca00e7
The aArgs parameter pack was already Forward'ed inside the constructor, so
maybe the '&&' was forgotten?
MozReview-Commit-ID: 7yg07axhZnp
--HG--
extra : rebase_source : dccd3ea5f0f1b6cadfe6bbc86c8ad34cb7f2c99e
Now that XRE_LibFuzzerGetFuncs is not used from outside libxul, it can
be inlined in LibFuzzerRunner::Run, simplifying things a little more.
--HG--
extra : rebase_source : 7a09f37444bf02983b232c964d85e7a866221f48
Going further from the previous changes, all libfuzzer_main really does
is call the init function, and then proceed to call the fuzzer driver
with the testing function.
So instead of calling that function for it to do all that, the
LibFuzzerRunner can just call the init function itself, and then
call the fuzzer driver with the testing function.
--HG--
extra : rebase_source : 2eb1a2ae763ef21827471cd32addceacefc1ac5d
The function given to XRE_LibFuzzerSetMain is called from somewhere that
does have access to argc/argv already, so we can avoid passing them
to XRE_LibFuzzerSetMain.
This actually might fix subtle issues with argc/argv not really matching
reality when calling the LibFuzzerMain function in the current code:
some arguments are handled before the call, and both argc and argv are
modified from within XRE_main, but the values stored for the
LibFuzzerMain call still are the original ones.
Argv being a pointer, and it not being reallocated, the value stored for
the LibFuzzerMain call points to the changed one, but argc, being an
integer, is not modified accordingly.
In fact, it's actually worse, because while the Gecko code doesn't
reallocate argv, gtk_main might. So if some GTK flag is passed on the
command line, there's also a possibility that the LibFuzzerMain function
will do a use-after-free.
So all in all, it's just better to use the set of modified argc/argv
from XRE_main instead of storing them from main().
--HG--
extra : rebase_source : 92b89909eab0fc2f67ce372b959bb0e3ed12cd2b
Nothing uses these defines, so we should remove them lest anybody get
confused. I would have also removed kAutoDetect (who would want to do
this?!), but kAutoDetect is used in one place in the tree, and I didn't
want to hold up the deletion of these two items with trying to fix that
one place.
Now that nothing is using those functions, we can remove them and limit
the scope of the standalone glue to initialize the new Bootstrap API.
--HG--
extra : rebase_source : b73845a207f8d6e632c46d089a00b7a67e1648fc
Reading application.ini involves using nsCOMPtr<nsIFile>, and that can
only happen through the XPCOM glue, which we eventually want to get rid
of.
So, while keeping the command line argument/environment variable
handling in nsBrowserApp, we move the actually parsing of the file to
XRE_main, where things can be handled without the XPCOM glue.
--HG--
extra : rebase_source : 487960a671476d4edae4f568c37efa6563ef4dff
Here, we also modify APKOpen to use the XPCOM glue loading process
instead of custom symbol resolution, so that the Bootstrap API can be
used in a more straightforward manner.
--HG--
extra : rebase_source : 55037ba30ca66a090b73923a3ce8df5b054bf47a
This is the first step towards changing how nsBrowserApp and other current
XPCOM glue users start up Gecko.
The goal here is to expose the same API via a single object with a
VTable instead of the current XPCOM glue machinery. Instead of creating
an entirely new API and changing everything to use it, we go forward
with smaller steps for a more comprehensible transition.
--HG--
extra : rebase_source : c2cf90ab3bb812b9ea75c70c9766f1a47ea50828
Instead of having nsBrowserApp.cpp set a flag in XREAppData to indicate
whether the DLL blocklist properly initialized, just have XRE code ask
the blocklist itself.
--HG--
extra : rebase_source : e872853481acce68b325909e476d009aec878701
This hasn't been used since the removal of the Metro code in bug
1039866, close to two years ago.
--HG--
extra : rebase_source : 58ec1ce63e4231c8006cafd3424675f14ddbf9f1
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382
OBSERVE_LATE_WRITES is now always defined, we can just remove it.
MozReview-Commit-ID: El6RnzZnXBN
--HG--
extra : rebase_source : 95fe63562b88c61ee5915e28a3a8b89c985042db
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
In the 32-bit parisc runtime, the first four non floating-point
arguments are passed in registers (%r26, %r25, %r24 and %r23).
The remaining arguments are passed on the stack. There are four
reserved slots on the stack that the callee can use to save the
first four argument registers if the callee desires.
The StubN functions are special in that arguments are not explicitly
declared. %r26 is used for the "self" pointer. The call to SharedStub(n)
loads n into %r26 and clobbers the "self" pointer in %r26. The hppa
SharedStub implementation expects to find the "self" pointer on the
stack in the slot reserved for StubN. However, gcc doesn't copy any
arguments to the stack as no arguments are declared for StubN. Even
if it did, there's no guarantee that we could force gcc to save the
argument on the stack as that's more expensive than copying to a
free register. Thus, we need to copy %r26 to the stack slot manually.
Bug 1295053 removed most uses of NS_METHOD and NS_CALLBACK, but one use was
unintentionally left behind (in the XPIDL parser) and another has since crept
in (in MediaDrmCDMProxy.h).
So this patch removes NS_METHOD and NS_CALLBACK. NS_METHOD_(nsresult) and
NS_CALLBACK_(nsresult, T) can still be used for the same purpose, but those
alternatives are less likely to be used unintentionally.
--HG--
extra : rebase_source : a50fc7b2a64a36d1ca9beda81bc0edb8f2ec1934
In some parts of the crash reporter, we need to disable I/O
interposition, then turn it back on. We didn't have a function for
re-enabling the I/O interposer...until now.
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 3ba0e13fb76ef2c5969084334c2f11e3f445d11f
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 40ad68820cfce469ecda272f430062f05dfcd09f
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 5c752e1a16af8e8f976853396228abff2c76c43c
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 3eb7fa3cb1873f71b4d5e7118d2dc48f6fdf2874
Implemented in the same style as RemovePointer and RemoveSmartPointer, for
consistency.
It could have been done by invoking the latter two, but I didn't want to add an
unnecessary extra layer of templates; the cost of the code duplication should
be negligible.
MozReview-Commit-ID: IH4lZkbRYGZ
--HG--
extra : rebase_source : b9b9a07a03fab768fc88b300c33627b3179a81da
Just a straight move, no code changes.
This will be needed in bug 1329319, as some new code higher in the file will
rely on RemoveSmartPointer. Since the next patch will pretty much rewrite
RemoveSmartPointer anyway, I thought I might as well make the big move
right now, to keep better history/blame of the upcoming changes.
MozReview-Commit-ID: A2lMUFHFWg4
--HG--
extra : rebase_source : 8470a0f7e2e6892e9d9c2e4eef1c44d8f73d2dad
Then and ThenPromise can now be given only one member function, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: 5Zm0i27GHcA
--HG--
extra : rebase_source : 1ed068681616fa0aa5fa77f8dbf78ccbd727f363
Then and ThenPromise can now be given only one function object, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: BEtc3spK9Yh
--HG--
extra : rebase_source : 1b16ad15ebfcdfb653d8d98073adee0f8b27b46e
Removed 'virtual' from overrides, as per coding guidelines.
Fixed some incorrect indentations, and inconsistencies.
MozReview-Commit-ID: 4kNVgoDljG3
--HG--
extra : rebase_source : 7b25abacc7cfc1a6898963bc58120204c70bee45
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
The point of this exercise is to make the thread name available in the thread
func of the thread, so that we can register the thread with the profiler from
the very start of its lifetime, and so that registration and unregistration
can be inside the same function.
MozReview-Commit-ID: DiiMKUQVr55
--HG--
extra : rebase_source : 24b15d56315ad49e72b3e9b76db7fb634f3bfe01
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 9deaace277db2f63c520325be27f6ed97aa65ac9
The point of this exercise is to make the thread name available in the thread
func of the thread, so that we can register the thread with the profiler from
the very start of its lifetime, and so that registration and unregistration
can be inside the same function.
MozReview-Commit-ID: DiiMKUQVr55
--HG--
extra : rebase_source : aa1d0c19250765c80c8e8ae59d2752bb4ad7eeac
The FileExists check can be removed because the code loading the library
will handle that case already.
--HG--
extra : rebase_source : bac53d3f88ed1dd716ee1340d40dae42becdfdf0
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
