Without this patch, these MOZ_ASSERT statements cause build errors, if I build
the layout/generic directory in non-unified mode.
(Instead of this patch, we could also hypothetically sprinkle individual
#includes for Assertions.h around to all the downstream files; but it's simpler
and more direct to just put it here in the file that contains the MOZ_ASSERT
statements in question. Note that many other MFBT headers also have includes
for Assertions.h, so it seems reasonable to include it here as well.)
Differential Revision: https://phabricator.services.mozilla.com/D125610
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
On some systems, uint_fast8_t may be as big as size_t! So the `static_assert(sizeof(aIndex) < sizeof(size_t))` could fail there. The better test here is to check for the expected type (uint_fast8_t).
Now, since uint_fast8_t can be bigger than 8 bits, we may as well choose it for variant sizes greater than 255, up to UINT_FAST8_MAX.
(The added parentheses help clang-format distinguish '<' for tests vs for templates.)
Differential Revision: https://phabricator.services.mozilla.com/D119574
When advancing to Beta, we stop adding sentinels after serialized data
in IPC::Message objects. These sentinels would cause all Extract calls
to not reach the end of the message buffer on Nightly. This patch fixes
an assertion failure which can occur when extract calls fully empty the
buffer, and the finished iterator is advanced by 0 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D118838
This should improve the performance of large calls to AdvanceAcrossSegments
when using a very large BufferList, as we no longer need to iterate over each
element to find the destination when the call is closer to the end.
This will be used most frequently with the new footer code to seek to the end
of an IPC message to read out the footer.
Differential Revision: https://phabricator.services.mozilla.com/D116667
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This should improve the performance of large calls to AdvanceAcrossSegments
when using a very large BufferList, as we no longer need to iterate over each
element to find the destination when the call is closer to the end.
This will be used most frequently with the new footer code to seek to the end
of an IPC message to read out the footer.
Differential Revision: https://phabricator.services.mozilla.com/D116667
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This is much simpler and lets us tidy up the addProperty code more. It also makes
it easier to change ShapeTable for property maps in the future.
Lookup performance and memory usage appear to be similar for the two versions,
probably because ShapeTable used the same double-hashing algorithm and because
we can purge most ShapeTables on GC.
Differential Revision: https://phabricator.services.mozilla.com/D113089
Allow using the MOZ_KnownLive function to get around it.
Use case is the following: I have an std::function member variable, and I want
that member to be able to capture `this`.
Using a strong reference creates a cycle and thus would leak. I know `this` to
always outlive the member, so it is fine to use a weak capture there.
Differential Revision: https://phabricator.services.mozilla.com/D111850
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
