My initial version of my patch for part 1 didn't have a "nothing" comment
because I copied the empty loop from somewhere that didn't have it. If
the comment is appropriate, let's make things consistent while I'm
touching this file anyways.
Differential Revision: https://phabricator.services.mozilla.com/D229500
For traversing an object that wraps a RefPtr and allows setting a new (copied)
value, but only has a const getter, like Canonical<RefPtr<T>> from
StateMirroring.h and Watchable<RefPtr<T>> from StateWatching.h.
Differential Revision: https://phabricator.services.mozilla.com/D224714
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
Also remove extra newlines between the frames of MOZ_ASSERT's stack trace.
__android_log_print already prints a newline.
Differential Revision: https://phabricator.services.mozilla.com/D227282
Add a ToTArray version that works with LinkedList.
This is much like what we do for other containers, but without walking the list
twice.
Differential Revision: https://phabricator.services.mozilla.com/D225001
Apparently rust bindgen uses a hack which assumes all specializations of
`UniquePtr` have the basic layout and use a pointer member with an empty
deleter.
This incorrect assumption unfortunately comes up for UniqueFileHandle,
which replaces the pointer type using the deleter with a file handle
helper type.
As this fails to build with RUST_BINDGEN, this patch takes the same
approach as bug 1802320, and just disables building these types when
building headers for bindgen.
This does not fix the general issue of bindgen making incorrect
assumptions about the layout of UniquePtr with non-default deleters.
Ideally, all non-default deleters should be made opaque.
Differential Revision: https://phabricator.services.mozilla.com/D223628
This is convenient in cross-platform code which needs to work with
`UniqueFileHandle` objects. `dup` is not supported by wasi, so the method isn't
available there.
Differential Revision: https://phabricator.services.mozilla.com/D221370
This makes sure we don't have associated global constructor.
It requires flagging some default constructor as constexpr, including
one from a union which we circumvent by adding a default field for the
uninitialized state of the union.
Differential Revision: https://phabricator.services.mozilla.com/D222799
This attribute can be used to guarantee that some global initialization take
place at compile-time, avoiding library loading overhead and static
initialization order fiasco.
Differential Revision: https://phabricator.services.mozilla.com/D222798
This is convenient in cross-platform code which needs to work with
`UniqueFileHandle` objects. `dup` is not supported by wasi, so the method isn't
available there.
Differential Revision: https://phabricator.services.mozilla.com/D221370
This makes sure we don't have associated global constructor.
It requires flagging some default constructor as constexpr, including
one from a union which we circumvent by adding a default field for the
uninitialized state of the union.
Differential Revision: https://phabricator.services.mozilla.com/D222799
This attribute can be used to guarantee that some global initialization take
place at compile-time, avoiding library loading overhead and static
initialization order fiasco.
Differential Revision: https://phabricator.services.mozilla.com/D222798
This requires to flag some method from Enumset as constexpr but make it
clear that those don't require a global constructor.
Differential Revision: https://phabricator.services.mozilla.com/D222792
Still rely on mozilla aliases though, for readability and to avoid
confusion in the case of NegativeInfinity.
As a bonus, provide MaxNumberValue that mirrors MinNumberValue.
Differential Revision: https://phabricator.services.mozilla.com/D222119
As per mozglue/static/README:
> mozglue/static contains parts of the mozglue library that can/should be
> statically linked to e.g. js/Gecko.
The compression part of MFBT is a good candidate for this.
Differential Revision: https://phabricator.services.mozilla.com/D221565
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
This lets us trigger a minor GC if we're allocating many long strings. This avoids
a memory spike on the test case reported in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D220388
Fixes the conversion in `mozilla::FloatingPoint` so we can add the specialisation
`mozilla::detail::FloatingPointTrait<js::float16>`.
And then update "TypedArrayObject.cpp" to directly use `mozilla::FloatingPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D217981
In `JSStringBuilder` (derives from `js::StringBuffer`) we now reserve space for the
`mozilla::StringBuffer` header in the internal vector. When creating a long string, we can
then directly initialize this header without having to move all characters in memory.
Differential Revision: https://phabricator.services.mozilla.com/D216694