Previously, part of the procedure we used to sanitize URLs entered via
the command line would check the host against the public suffix
database. This led to some valid, but not publicly accessible URLs
being treated as invalid.
The IntlMV is meant to be arbitrarily precise. If the user provides a
string value to be formatted, we lose precision by converting extremely
large values to a double. We were never able to address this, as support
for arbitrary precision was a big FIXME. But ICU can handle it by just
passing the raw string on through.
This uses ICU for the Intl.NumberFormat `formatRange` and
`formatRangeToParts` prototypes.
Note: All of the changes to the test files in this patch are now aligned
with both Chrome and Safari.
This uses ICU for the Intl.NumberFormat `format` and `formatToParts`
prototypes. It does not yet port the range formatter prototypes.
Most of the new code in LibLocale/NumberFormat is simply mapping from
ECMA-402 types to ICU types. Beyond that, the only algorithmic change is
that we have to mutate the output from ICU for `formatToParts` to match
what is expected by ECMA-402. This is explained in NumberFormat.cpp in
`flatten_partitions`.
This lets us remove most data from our number format generator. All that
remains are numbering system digits and symbols, which are relied upon
still for other interfaces (e.g. Intl.DateTimeFormat). So they will be
removed in a future patch.
Note: All of the changes to the test files in this patch are now aligned
with both Chrome and Safari.
Turns out vcpkg does not yet support Universal binaries. While they are
working on it, lets produce arm64 binaries only for now to unblock the
pipeline.
This change allows the results of a find in page query to be reported
back to the user interface. Currently, the number of results found and
the current match index are reported.
Before we had HTTP::HeaderMap (which preserves multiple headers with the
same name), we collected multiple "Set-Cookie" headers and bundled them
together as a JSON array.
This was a huge hack, and now we can stop doing that, since LibWeb gets
access to the full set of headers now.
Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...>
everywhere, we now encapsulate this in a class.
Even better, the new class also allows keeping track of multiple headers
with the same name! This will make it possible for HTTP responses to
actually retain all their headers on the perilous journey from
RequestServer to LibWeb.
The [UTF-8](https://datatracker.ietf.org/doc/html/rfc3629#page-5)
standard says to reject strings with upper or lower surrogates. However,
in many standards, ECMAScript included, unpaired surrogates (and
therefore UTF-8 surrogates) are allowed in strings. So, this commit
extends the UTF-8 validation API with `AllowSurrogates`, which will
reject upper and lower surrogate characters.
Adds all the arithmetic ops for f32x4 and f64x2 SIMD instructions.
With this, we pass 8375 additional tests :)
Quite a few of the spec tests for this are still failing.
I confirmed with the wasmer runtime manually for a number of them,
and we seem to match their and results. I'm not really sure
what's happening here, a spec bug or wasmer is broken in
the same way.
18476 failed before.
10101 failed after.
Note: We keep locale parsing and syntactic validation as-is. ECMA-402
places additional restrictions on locales above what is required by the
Unicode spec. ICU doesn't provide methods that let us easily check those
restrictions, whereas LibLocale does. Other browsers also implement
their own validators here.
This introduces a locale cache to re-use parsed locale data and various
related structures (not doing so has a non-negligible performance impact
on Intl tests).
The existing APIs for canonicalization and display names are pretty
intertwined, so they must both be adapted at once here. The results of
canonicalization are slightly different on some edge cases. But the
changed results are actually now aligned with Chrome and Safari.
Rather than removing LibLocale entirely, we will use it as a wrapper
around ICU (which has some C-like interfaces, and uses UTF-16 for its
string types). Using ICU will provide better web compatibility overall,
and will let us implement features we were previously unable to (e.g.
Intl.Collator requires data that is not in the JSON export of the CLDR).
