This fix simply ignores tablet mode when running on Windows 11. The
reasoning behind this is that per Microsoft documentation tablet mode
is specific to Windows 10 and not supported anymore on Windows 11. This
seems consistent in the behavior of the APIs we use to detect the
presence of a keyboard: Windows 10-specific APIs return unexpected
results while APIs that predate them return values that seem consistent
and reliable.
Differential Revision: https://phabricator.services.mozilla.com/D128229
Generalize RandomUint64() into a new GenerateRandomBytes() function, which will be used in the next changeset to replace nsUUIDGenerator's various platform-specific implementations with one simple implementation.
Differential Revision: https://phabricator.services.mozilla.com/D124311
The next patches remove elements from a segmented vector that is being
iterated. This patch adds assertions to ensure that we don't attempt to use an
iterator that points to a removed element.
The assertions are added to Done() because all the other methods call that.
Differential Revision: https://phabricator.services.mozilla.com/D125426
The next patches remove elements from a segmented vector that is being
iterated. This patch adds assertions to ensure that we don't attempt to use an
iterator that points to a removed element.
The assertions are added to Done() because all the other methods call that.
Differential Revision: https://phabricator.services.mozilla.com/D125426
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