In case Unicode adds additional alternate spaces to formats in the future, the wsCompat argument will be ready.
I also switched over to the `u_isUWhiteSpace` alias, which is functionally identical to `UCHAR_WHITE_SPACE` at present, just in case the alias ever expands beyond the const.
The problem here is that we use move assignment on a hash table entry that
is not live. Although all entries are constructed by
`HashTable::createTable`, they may subsequently be destroyed by
`HashTableEntry::destroyStoredT()`.
Therefore it is not safe to call any methods on a non live entry.
This causes a problem for GC barrier wrappers which assume that the object
state is valid (and presumably anything that does more than just write the
assigned data into memory).
The fix is to construct a new entry in-place.
Based on work by Jon Coppeard <jcoppeard@mozilla.com> in Bug 2009608
ICU replaced the space prefixing the period with a narrow, non-breaking space, and occasionally, a thin space.
Until the rest of the world's scripts are ready to support this new convention, we un-replace these two whitespace characters with spaces again, but only in formatted dates and times.
This is not an ideal solution, as it could be possible that a custom format using one or both of these characters may be requested intentionally elsewhere in the string, but for now, this appears to be what other browsers do, so we're at least in parity with their edge case behavior.
This puts in a reduced-register version of Xoroshiro128++ which /just/
fits in our x86 7-register space by making use of an extra mState to
temporarily store the result to be passed back.
Resolves#2895
The jit assembly implementation of Xoroshiro128++ on 64-bit platforms is
unsuitable for 32-bit because it requires more registers than our jit
can reasonably provide (7 usable/8 total), causing run-time issues.
As a workaround for this, this commit splits the jit version of PRNG up
into Xorshift128+ for 32-bit targets and Xoroshiro128++ everywhere else.
The C++ version in MFBT remains Xoroshiro128++ on all platforms.
While not ideal, the PRNG on 32-bit will still be suitably performant and
with small enough deviations for all practical purposes in Math.random()
in JavaScript. Since this is a PRNG, there are no concerns about
reproducibility of results, only proper statistical distribution of values.
Also some drive-by corrections to comments in MFBT:
- Incorrect statement that the period is 2^256-1. It is 2^128-1
- More readable comments by using standard operator characters for power.
Resolves#2895 (again)
Register64 isn't natively supported on 32-bit targets (ARM, MIPS32, x86)
so they require initializers with 2 32-bit register components.
Also, `rotateLeft64()` requires a temp register on 32-bit targets.
Fix compile issue with MacPorts GCC 14.
Fix null pointer dereference in OpenGL compositor.
Fix recurcursive font loading due to TenFourFox code drift.
Fix LazyScript size mismatch in debug builds.
Fix crash due to missing auto release pool in debug builds.
Fix keyboard input crash due to incorrect code disabling.
Fix mouse events never having button pressed state.
x86/x64 MacroAssembler front-end rotate functions had comparison asserts
that do not seem to be correct; values being the same doesn't mean the
same regs were used.
Surrounding structures remain the same because the bit width remains 128.
The more complicated algorithm requires more temp registers in LRandom
to account for intermediate result placeholders in the JITed version of
this algorithm.
Basilisk-Dev
Moonchild
Job Bautista
Brian Smith
Andy