Remove some type-level indirections from template-metaprogramming
helpers.
Additionally, replace some nearby uses of `typedef` with `using`, as
suggested by clang-tidy.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D201784
When compiled with -std=c++17, u8"" string literals have type `const char[]`. When compiled with -std=c++20, u8"" string literals have type `const char8_t[]`. This patch adds the minimum char8_t overloads needed to compile Firefox with -std=c++20. If we want to use char8_t in more code or replace `Utf8Unit` with char8_t, that will require an extensive redesign of MFBT's and xpcom's string classes after we update from -std=c++17 to c++20.
Differential Revision: https://phabricator.services.mozilla.com/D201672
The built-in version is better as it also allows annotating particular
parameters (it not only applies to method declarations).
Differential Revision: https://phabricator.services.mozilla.com/D200432
The built-in version is better as it also allows annotating particular
parameters (it not only applies to method declarations).
Differential Revision: https://phabricator.services.mozilla.com/D200432
This prevents it from being used in the foot-gunny way described in
comment 0.
This in turn allows us to add a constructor for temporary callables.
Turns out we only had test usages of non-temporary FunctionRefs, so this
is much simpler than the initial approach I considered.
Fix the tests to keep compiling, and add a test for the new constructor.
Differential Revision: https://phabricator.services.mozilla.com/D200157
size_t is already correctly used in many places, only ConstIterator uses
uint32_t for position tracking. It would be better to align these data types
and use size_t everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D197774
MozTaggedMemoryIsSupported doesn't work under ASAN because it tries to prctl the
nullptr page. It should be harmless to simply call prctl and ignore the error.
Depends on D195064
Differential Revision: https://phabricator.services.mozilla.com/D195065
Remove all of the code in `RefPtr` and `AgileReference` that allowed
for implicitly converting between the two in via constructors or the
assignment operator.
Replace these with a slightly-less-convenient-but-substantially-more-
explicit `Resolve` function family.
(This also eliminates the dependency that `class RefPtr` had on
`class AgileReference`.)
Differential Revision: https://phabricator.services.mozilla.com/D196365
Remove all of the code in `RefPtr` and `AgileReference` that allowed
for implicitly converting between the two in via constructors or the
assignment operator.
Replace these with a slightly-less-convenient-but-substantially-more-
explicit `Resolve` function family.
(This also eliminates the dependency that `class RefPtr` had on
`class AgileReference`.)
Differential Revision: https://phabricator.services.mozilla.com/D196365
In the fx codebase, we tend to use __attribute__((naked)) for plain
assembly functions with a C interface. Instrumenting these functions can
mess up this assembly, so we conservatively also want to prevent
instrumentation.
Differential Revision: https://phabricator.services.mozilla.com/D196154
The patch implements the move assigment operator in terms of the move
constructor. This fulfills the requirements for std::swap to compile.
Differential Revision: https://phabricator.services.mozilla.com/D196035
The patch implements the move assigment operator in terms of the move
constructor. This fulfills the requirements for std::swap to compile.
Differential Revision: https://phabricator.services.mozilla.com/D196035
This patch makes mingwclang builds compile with -include _mingw.h. This
makes MSVC-style constants defined from the start of C++ files rather
than at the point where they start including files that depend on
_mingw.h. Thus, mingwclang builds will behave more closely to regular
builds, potentially avoiding future backouts for mingwclang build
failures and/or successful but incorrect mingwclang builds.
Differential Revision: https://phabricator.services.mozilla.com/D195662
In order to use mozilla::Result with integral, pointer, or enum, without
consuming extra space or introducing extra instruction, reserve 0 as error value
in the underlying representation.
Differential Revision: https://phabricator.services.mozilla.com/D191537
In order to use mozilla::Result with integral, pointer, or enum, without
consuming extra space or introducing extra instruction, reserve 0 as error value
in the underlying representation.
Differential Revision: https://phabricator.services.mozilla.com/D191537
If someone tried to serialize a zero-size ByteBuf, it could add a
zero-length segment to the `BufferList` and cause an assertion failure
later when trying to send the message. This patch makes it a no-op (and
frees the supplied buffer, because the BufferList becomes its owner).
We previously asserted against adding zero-*capacity* segments (likely
also zero size, but possibly not) with WriteBytesZeroCopy, but only on
debug builds, and it was likely happening on release builds despite
that. That case is now allowed.
Also, error handling for `BufferList::WriteBytesZeroCopy` has been
improved. (This doesn't affect `Pickle` because it's using infallible
allocation, and no other instances of `BufferList` seem to use
`WriteBytesZeroCopy` at this time.)
Differential Revision: https://phabricator.services.mozilla.com/D192531
Without this, the necessary synchronization must be provided externally.
This fixes the memory order in the following case of changing producer thread:
- Thread A does SPSCQueue::Enqueue
- non-atomic write into the ring buffer, at memory location X
- mWriteIndex.load(relaxed)
- mWriteIndex.store(release)
- Producer thread is switched to B, no external memory order synchronization is
provided, but thread B is guaranteed to run after thread A has finished its
Enqueue task.
- Thread B does SPSCQueue::Enqueue
- mWriteIndex.load(relaxed)
- mWriteIndex.store(release)
- Thread C does SPSCQueue::Dequeue
- mWriteIndex.load(acquire)
- non-atomic read from the ring buffer, at memory location X
In this scenario, there is no memory synchronization between threads A and B,
and therefore the non-atomic read on C is a data race, and flagged as such by
TSAN.
A similar scenario can be applied to changing the consumer thread, if first A
enqueues, then B dequeues, then C dequeues. However, since Dequeue doesn't
necessarily (MoveOrCopy) do non-atomic writes to the ring buffer, and more
importantly, since Enqueue doesn't do non-atomic reads from the ring buffer,
this is less of a problem.
Differential Revision: https://phabricator.services.mozilla.com/D190084
Starting with Windows 11 22H2, Microsoft has made internal changes in
msctf.dll. The TF_Notify function, also known as CtfImmNotify from
imm32.dll, uses a new convention for its third argument. These changes
are incompatible with current versions of ZoneAlarm Anti-Keylogger,
resulting in crashes in our main process.
This patch converts messages forwarded by ZoneAlarm Anti-Keylogger to
the new convention. If we detect the product and an incompatible version
of msctf.dll, then we hook TF_Notify and detect any message using the
old convention, and convert it to the new convention.
Differential Revision: https://phabricator.services.mozilla.com/D189518
Arbitrary capability names weren't allowed until clang 11, and while we
could probably make things somehow work with earlier versions of clang,
it's not that interesting, as long as we keep the thread safety analysis
running with newer versions of clang on our CI (which we obviously do).
Differential Revision: https://phabricator.services.mozilla.com/D188791
* DefaultHasher<T*> used HashGeneric<size_t>
* nsPtrHashKey<T> used HashGeneric<T*>
* nsRefPtrHashKey<T> used NS_PTR_TO_UINT32 >> 2
Make sure to always use HashGeneric<T*> for these.
Remove unused / redundant hash keys.
Differential Revision: https://phabricator.services.mozilla.com/D186553
In bug 1839743, we made the build system prefer packed relative
relocations to elfhack when both the system libc and linker support
them. Unfortunately, while that covers most of the benefits from
elfhack, it doesn't cover bug 651892.
To cover it, we make every C++ executable contain its own copy of
the symbol, so that all relocations related to it become relative.
And because this is actually (slightly) beneficial on macos, and because
it's also an advantage to have our own abort called rather than the
system's, we apply the same to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D184068
In bug 1839743, we made the build system prefer packed relative
relocations to elfhack when both the system libc and linker support
them. Unfortunately, while that covers most of the benefits from
elfhack, it doesn't cover bug 651892.
To cover it, we make every C++ executable contain its own copy of
the symbol, so that all relocations related to it become relative.
And because this is actually (slightly) beneficial on macos, and because
it's also an advantage to have our own abort called rather than the
system's, we apply the same to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D184068
All event targets should be threadsafe and implemented in C++, and so should be
able to be used in `Sync` types in Rust code.
This also required annotating all interfaces deriving from `nsIEventTarget`, as
well as adding some associated constants to specific types to indicate to the
static assertion that they have threadsafe reference counts.
Differential Revision: https://phabricator.services.mozilla.com/D183592
All event targets should be threadsafe and implemented in C++, and so should be
able to be used in `Sync` types in Rust code.
This also required annotating all interfaces deriving from `nsIEventTarget`, as
well as adding some associated constants to specific types to indicate to the
static assertion that they have threadsafe reference counts.
Differential Revision: https://phabricator.services.mozilla.com/D183592
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
clang is warning that C++20 expects comparison operators to be commutative: `a == b` and `b == a` should resolve to the same comparison operator function. Warnings about the comparison of const and non-const objects can be fixed by making the comparison operator function const.
mfbt/tests/TestDoublyLinkedList.cpp:158:36 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'SomeClass' and 'SomeClass') to be ambiguous despite there being a unique best viable function
mfbt/tests/TestDoublyLinkedList.cpp:159:38 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'SomeClass' and 'SomeClass') to be ambiguous despite there being a unique best viable function
Depends on D179022
Differential Revision: https://phabricator.services.mozilla.com/D179023
Paul Adenot
Andreas Pehrson
Stanca Serban
Norisz Fay
Ray Kraesig
Peter Van der Beken
Natalia Csoregi
serge-sans-paille
Kelsey Gilbert
Chris Peterson
Christian Holler (:decoder)
Emilio Cobos Álvarez
pstanciu
Jan Varga
maazis
Mathew Hodson
Mike Hommey
Jed Davis
Tom Marble
Benjamin Peterson
Sandor Molnar
Jon Coppeard
Yannis Juglaret
Paul Bone
Sylvestre Ledru
Iulian Moraru
Gabriele Svelto
Tooru Fujisawa
Daniel Holbert
Nika Layzell
Masatoshi Kimura
Steve Fink
Noemi Erli
Ryan VanderMeulen
Markus Stange
Tyson Smith
André Bargull
Cristina Horotan
Jesse Schwartzentruber
Nicolas B. Pierron
Cosmin Sabou