Allow MOV with GS prefix on x64. Windows 10 uses this opcode on GetKeyState().
MozReview-Commit-ID: CqDSxmWdkiH
--HG--
extra : rebase_source : aa83b2b4c141730eb89f29cad61af79e66cb7a71
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 7cfc08e62de49de869b97ae96630db573f882f18
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
Bug 1263355 changed scopes from JSObjects (which are represented in
the CC graph) to a new kind of GC thing. Many objects can share the
same scope, so they will end up calling the scope trace method
repeatedly, causing cycle collections to become much slower in some
cases.
MozReview-Commit-ID: CFO87zXjwgu
The invoke_copy_to_stack() function passes incorrect "stack_args" and
"end" arguments to the alloc_word() utility function, for parameter types
T_I8..T_I64, T_U8..T_U64, T_BOOL, T_CHAR and T_WCHAR.
Namely, the "end" input parameter of invoke_copy_to_stack(), which is
currently incorrectly passed as "end" to alloc_word(), points to the very
end of the entire exchange area between _NS_InvokeByIndex() and
invoke_copy_to_stack(). However, alloc_word()'s "end" parameter should
point to the end of the "ireg" (integer registers) sub-area of the
exchange area. That is, "ireg_end" should be passed to alloc_word() as
"end".
Because invoke_copy_to_stack()'s "end" input parameter is strictly greater
than "ireg_end", alloc_word() will happily trample over the "freg"
(floating point registers) area, on the above-mentioned type branches,
given a large enough "paramCount".
Similarly, as second argument, "stack_args" should be passed to
alloc_word(), pointing to the next available stack slot, for spilled-over
arguments. Passing "stk", which initially points to the base of the entire
exchange area (and hence the base of the "ireg" area) makes no sense.
The two other alloc_word() calls in the function are correct. So
centralize all calls to alloc_word() to a single location -- thereby
ending up with a sole call site per alloc_XXX() function --, and compute
only the last argument, "word", conditionally.
This fixes an obscure SIGSEGV in AARCH64 Firefox. Triggering the bug
requires a target function with seven integer-like parameters (not
counting the implicit "this" -- aka "that" -- parameter), followed by at
least one parameter of the above buggy types. nsIOService::NewChannel2()
is such a target function, for example.
DONTBUILD because NPTOB
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
nsThreadManager::get() can return a reference. This lets us remove some
redundant assertions.
nsThreadArray elements can be NotNull<>s.
--HG--
extra : rebase_source : fd49010167101bc15f7f6d01bf95fd63b81d60fb
Removed '#ifndef XPCOM_GLUE' that blocked usage of thread-safe ref-counting
from XPCOM_GLUE code.
MozReview-Commit-ID: Hm0rdTKK46l
--HG--
extra : rebase_source : cd2779d0b39c5319cfdb5d12e8f4ac6f38945e7b
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
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
We have a number of nsTHashtable<nsPtrHashKey<T>> instantiations, mostly
from IPDL-generated code. There's no reason in principle that all of
these instantiations couldn't share code, since they're all storing POD
entries of the same size. Let's specialize nsTHashtable for such types,
providing a thin layer over a hashtable that stores void pointers. This
change saves about 90K of space (!) on x86-64 Linux.
The standard placement new function is declared to not throw, which
means that, per spec, a null check on its result is required. There are
a number of places throughout xpcom/ where we know that we are passing
non-null pointers to placement new (and receiving them as a return
value), and we are therefore doing useless work performing these null
checks.
Therefore, we should be using an operator new overload that doesn't
require the null check. MFBT has just such an overload, so use that.
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
I think technically you could implement one of these in JS now, which
might prevent me from reasonably asserting that these can never GC. I
doubt anybody would ever do that, so it should be okay. There are zero
references to these two interfaces in all of addon DXR, and none in
Firefox JS.
MozReview-Commit-ID: 3AkW0AkqmNx
This is the same basic idea as NS_IMPL_RELEASE_WITH_DESTROY. I need
this because I am making XPCNativeInterface refcounted, and it uses
some weird placement new stuff requiring a special function to
deallocate the object. (It does this to store an array of arbitrary
length inline, presumably for some sort of time or space reason.)
MozReview-Commit-ID: 5I7BgY6YlLl
The patch also makes GetInputStream() fail if the pipe isn't initialized, just
like GetOutputStream().
--HG--
extra : rebase_source : 7391b331ffe25e0ac7ebc755f7da313dc7b5517d
For XPIDL methods, this causes MOZ_MUST_USE to be prepended to the generated
C++ function declaration.
For XPIDL attributes, this causes MOZ_MUST_USE to be prepended to the generated
C++ getter declaration and (if present) setter declaration.
--HG--
extra : rebase_source : e0b2c43235bfbc02db609076e82ca6325e4b0bff
This is the same basic idea as NS_IMPL_RELEASE_WITH_DESTROY. I need
this because I am making XPCNativeInterface refcounted, and it uses
some weird placement new stuff requiring a special function to
deallocate the object. (It does this to store an array of arbitrary
length inline, presumably for some sort of time or space reason.)
MozReview-Commit-ID: 5I7BgY6YlLl
mozilla::function involves an allocation of the FunctionImpl type, that we can
avoid rather easily in this case.
This commit is completely optional, I guess, though the code we're using
RemoveElementsBy with the previous patch is sort of hot.
MozReview-Commit-ID: 2LoQs4cB28X
The standard placement new function is declared to not throw, which
means that, per spec, a null check on its result is required. There are
a number of places throughout xpcom/ where we know that we are passing
non-null pointers to placement new (and receiving them as a return
value), and we are therefore doing useless work performing these null
checks.
Therefore, we should be using an operator new overload that doesn't
require the null check. MFBT has just such an overload, so use that.
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 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 the following changes on many in-class methods.
- NS_METHOD F() override; --> NS_IMETHOD F() override;
- NS_METHOD F() override {...} --> NS_IMETHOD F() override {...}
- NS_METHOD F() final; --> NS_IMETHOD F() final;
- NS_METHOD F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 3010fade82a170eab7f13d81bf61b02cd693f3cf
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
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
NS_OBJC_{BEGIN,END}_TRY_LOGONLY_BLOCK{,RETURN} are identical to
NS_OBJC_{BEGIN,END}_TRY_ABORT_BLOCK{,RETURN}. This patch removes the LOGONLY
versions in favour of the ABORT versions.
--HG--
extra : rebase_source : 4537de8986b87784d2a80ead24999310adbdece8
Including the PID makes it impossible to aggregate crash reports on
crash-stats.
This also reduces buffer size to ensure that having two buffers does
not increase total stack size, though that is unlikely to matter. 1000
characters is likely excessive in any event.
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
The backwards copying case in MoveOverlappingRegion had a bug: rather
than destroying each element from the source range as we moved it, we
would always destroy the element at the beginning of the source range.
Fortunately, none of the existing types that were copied via
constructors seem to trigger the problematic code.
In all of the calls to CopyNonOverlappingRegion from within nsTArray, we
don't care about the contents of the source afterwards. So we can use
moves instead of copies to potentially make things more efficient.
Whenever we're copying the header, we can be guaranteed that we're never
going to use the elements from the old array afterward, so can move (in
the C++ sense) the elements rather than copying them.
We'll need these for future patches as we transition nsTArray to use
moves for most of its operations rather than copies. The implementation
of these functions are essentially cut-and-paste versions of the Copy*
functions, but using moves.
The names {Copy,Move}Elements are based on the use of mem{cpy,move},
respectively. However, I submit that we really want the names to
reflect the C++ operations being done, rather than the underlying
implementation details. So let's rename these to reflect that we are
always copying the elements, and discriminate between the two cases
based on whether the regions being copied overlap or not.
Bring CopyHeaderAndElements along for the ride, as well.
This change enables some of the methods in nsTArray to be lazily
instantiated, particularly the ones that care about whether the element
type is copyable. Since we have a number of places where nsTArray is
used with move-only types, we need to ensure that unless methods
requiring copyability are actually called, those methods are not
instantiated.