Thread UTF-16 string input through JSON, script parsing, Date parsing,
Intl option parsing, Temporal parsing, and the helper library boundaries
that feed those parsers. Preserve ASCII fast paths where the source data
is known to be ASCII.
Move the remaining LibJS primitive string users to UTF-16 views and
strings. Remove the primitive string UTF-8 accessors and byte-string
coercion paths so new callers cannot rely on the old storage model.
Keep primitive string storage in Utf16String and remove the UTF-8
storage path from PrimitiveString. ASCII strings still use compact
Utf16String ASCII storage, while UTF-16 becomes the only owned
representation.
Build JSON.stringify, Date ISO strings, and Temporal string results with
Utf16StringBuilder when the result is consumed as a JavaScript string.
Keep UTF-8 conversion only at callers that explicitly need bytes outside
LibJS.
Port straightforward JS string construction sites to Utf16StringBuilder.
Make ASCII appends explicit with append_ascii(), and leave byte-output,
formatted-output, and printer plumbing on StringBuilder where that API
still matches the caller.
Add a small checked JS string length product helper. Use it for
String.prototype.repeat() before constructing the repeated result. Keep
the maximum string length policy in LibJS while allowing the UTF-16
builder to remain purpose-built and infallible. Cover overflow from the
final repeated code-unit length in the repeat tests.
Enable -Wexit-time-destructors for all in-tree library targets and
update process-lifetime library statics so they no longer register
exit-time destructors. Long-lived caches, lookup tables, singleton
registries, and generated constants now use NeverDestroyed or leaked
references where the data is intended to live until process exit.
Update LibWeb, LibLine, and the binding generators so regenerated
sources follow the same rule instead of reintroducing destructed
statics.
Same as commit f9fa548d43.
These are String from the outset, so this patch is almost entirely just
changing function parameter types. This will allow us to cache calendar
objects in ICU without invoking any extra allocations.
These are String from the outset, so this patch is almost entirely just
changing function parameter types. This will allow us to cache time zone
parse results without invoking any extra allocations.
I don't fully understand the BigInt math here, as the computation for
d1 and d2 don't align with the spec due to BigInt logic. This was
discussed a bit in SerenityOS's Discord some years ago:
https://discord.com/channels/830522505605283862/851522357734408232/978786665306918932
But some new tests in test262 indicate that we need to handle negative
values here, instead of just throwing away the sign.
This is an editorial change in the Temporal proposal. See:
https://github.com/tc39/proposal-temporal/commit/96bb9b0
Note that we already had a struct for this, but now that it has a proper
name and spec link, this renames it to match other Parse Records and
places it alongside them.
This concept is rarely used in codebase and very much error-prone
if you forget to check it.
Instead, make it so that operations that would produce invalid integers
return an error instead.
These are going to be included in the ECMA-262 AOs once Temporal reaches
stage 4. There's no need to keep them in the Temporal namespace. Some
upcoming Temporal editorial changes will get awkward without this patch.
We were passing types like ISODate by reference so that they could be
used as forward-declarations. But after commit 021a5f4ded, we now have
their full definitions anywhere they're needed. So let's pass ISODate by
value everywhere consistently - it is only 8 bytes.
Currently, AbstractOperations.h needs to include Time.h for the Time
structure. Soon, Time.h will need to include AbstractOperations.h for
structures defined there. To avoid a circular include, let's put the
ISO types into their own file, so that AO.h does not need to include
any JS type header.
Our BigInt implementation can store the negativity of the division
result in either the quotient or the remainder. This is exposed by an
upcoming prototype, which will reach this division with:
-432000000000000 / 86400000000000000000000
Which has the BigInt division result:
quotient = 0
remainder = -432000000000000
(Our old Temporal implementation also had this bug).
We now have the Temporal facilities to implement the Date AOs which
parse UTC offset strings using the ISO8601 parser. This patch updates
those AOs and their callers in accordance with the Temporal spec.
