This does a few minor improvements:
1. Adds implicit conversions from NotNull to a raw pointer type if supported by
the underlying type, to make it so NotNull<RefPtr<T>> acts more like
RefPtr<T> in some situations.
2. Adds explicit conversion constructors and assignment operators for RefPtr
and nsCOMPtr from NotNull, avoiding conversion ambiguity added by the first
change.
3. Disable conversion constructors on NotNull with SFINAE if they should not be
available, meaning that type traits like std::is_convertible_v interact with
it properly.
Differential Revision: https://phabricator.services.mozilla.com/D168883
We define a new MOZ_HAVE_NO_STACK_PROTECTOR modifier attribute. It is
mapped to __attribute__((no_stack_protector)) and specifies that a given
function should *NOT* be instrumented to detect stack buffer overflows
at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D171361
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
C++20 deprecated decrement/increment of object of volatile-qualified types, e.g. v++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r3.html
mfbt/SHA1.cpp:400:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:401:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:402:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:403:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:404:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
shaCompress() has a comment emphasizing the importance of the X array being volatile. I verified that changing `XH(0) += A` to `XH(0) = XH(0) + A` generates the same -S assembly code (for clang -O2 on Apple Silicon).
Whether this comment about the volatile code generated by gcc 3.4.3 -O3 in 2012 is still relevant for clang 15 -O2 in 2023 is a different question.
Differential Revision: https://phabricator.services.mozilla.com/D165268
The annotations added in bug 1770158 only covered `StringToDouble`,
however as noted in the comments in that file, that isn't sufficient for
accurately parsing floating point numbers. This patch extends the
annotations to the single-precision floating point numbers as well and
will be used in the next part to clean up the implementation of
`nsTString::ToDouble`.
Differential Revision: https://phabricator.services.mozilla.com/D148304
It's unclear to me when they were disabled, but we do want to enable
these as otherwise there's no way to catch bindgen issues that can end
up in subtle bugs at best, or memory corruption at worst.
Differential Revision: https://phabricator.services.mozilla.com/D162997
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
Some profiling of tcampbell's React benchmark [1] shows 6.1 million calls to
js::frontend::GeneralTokenStreamChars<..>::getFullAsciiCodePoint, using 110.57
million instructions (x86_64). That comes out to only 18 insns per call,
which suggests the method is a good candidate for inlining, but it isn't
inlined.
Merely parking an inline annotation on it doesn't help much, because it gets
inlined into js::frontend::TokenStreamSpecific<..>::getCodePoint, but that
isn't inlined into *its* caller(s), so the 6.1 million calls move to
::getCodePoint instead.
This patch requests inlining for both ::getFullAsciiCodePoint and
::getCodePoint and adds some MOZ_NEVER_INLINE annotations to ensure that cold
paths *don't* get inlined into these two, to reduce code bloat and avoid
excessive register pressure.
IsAscii functions in mfbt/TextUtils.h have been marked inline as a precaution;
this probably isn't necessary.
Run time with config [2] is reduced from 0.390 seconds to 0.379 seconds
(2.8% speedup, best of 50 runs), and from 0.402 to 0.396 seconds
(median of 50 runs).
Instruction count falls from 3511.8 million to 3395.8 million, and the number
of data accesses from 1563.7 million to 1487.4 million -- a 4.8% reduction
that is probably caused by avoidance of save/restore sequences in the inlined
fns.
[1] https://github.com/mozilla-spidermonkey/matrix-react-bench
[2] Fedora 35, x86_64, Intel Core i5 1135G7 at 4 ish GHz
configure: --disable-debug --enable-optimize="-g -O2"
run: --no-threads
Differential Revision: https://phabricator.services.mozilla.com/D159500
The only uses of this method were removed in Part 1, meaning that it can
now be removed. Support for this method adds a significant amount of
complexity to `BufferList` and IPC serialization.
Differential Revision: https://phabricator.services.mozilla.com/D154439
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
The next patch is creating a cache which is capable of looking up different kind
of string types. However, each string type need some contextual information to
be able to compare them against each others, which adds complexity to the lookup
type. In addition, the keys are of only one string type, and therefore we try to
avoid storing this context as part of each key, but instead provide it with the
contextual information coming with the Lookup type.
Therefore, when we want to insert a key, which might already be present, using
`put`. We have to provide a `aLookup` argument which knows how to compare keys.
This also make the interface similar to `putNew` which already has the
distinctions between the `Lookup` argument and the `KeyInput` argument.
Differential Revision: https://phabricator.services.mozilla.com/D154512
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Differential Revision: https://phabricator.services.mozilla.com/D154619
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Differential Revision: https://phabricator.services.mozilla.com/D154617
