This allows us to only perform checks like export bindings existing only
for modules. Also this makes it easier to set strict and other state
variables with TemporaryChanges.
In static init blocks 'await' cannot be used. Note that this does not
cover all the cases since the parser currently cannot distinguish
between expressions within parenthesis and direct expressions.
This makes it a lot easier to understand what is going wrong when an
eval test fails. As an example instead of just getting:
`ExpectationError`
You would now get:
`ExpectationError: Expected _1_2E+0_1_ to eval to _12_ but got _120_`.
For example, consider the following adjacent entries in UnicodeData.txt:
3400;<CJK Ideograph Extension A, First>;Lo;0;L;;;;;N;;;;;
4DBF;<CJK Ideograph Extension A, Last>;Lo;0;L;;;;;N;;;;;
Our current implementation would assign the display name "CJK Ideograph
Extension A" to code points U+3400 & U+4DBF, but not to the code points
in between. Not only should those code points be assigned a name, but
the Unicode spec also has formatting rules on what the names should be
(the names for these ranged code points are not as they appear in
UnicodeData.txt).
The spec also defines names for code point ranges that actually are
listed individually in UnicodeData.txt. For example:
2F800;CJK COMPATIBILITY IDEOGRAPH-2F800;Lo;0;L;4E3D;;;;N;;;;;
2F801;CJK COMPATIBILITY IDEOGRAPH-2F801;Lo;0;L;4E38;;;;N;;;;;
2F802;CJK COMPATIBILITY IDEOGRAPH-2F802;Lo;0;L;4E41;;;;N;;;;;
Code points are only coalesced into a range if all fields after the name
are equivalent. Our parser will insert the range and its name formatting
pattern when it comes across the first code point in that range, then
ignore other code points in that range. This reduces the number of names
we generated by nearly 2,000.
When calling set_selected_index() on ComboBox, allow its on_change
callback to be disabled. Fixes FontEditor window state erroneously
switching to modified when initializing between different slopes
and weights.
GlyphBitmaps are considered present if they have a width greater
than zero. This adds a counterpart method for raw (unmasked) glyphs
and makes intent more explicit throughout FontEditor.
This adds plumbing for the Intl.DateTimeFormat object, constructor, and
prototype.
Note that unlike other Intl objects, the Intl.DateTimeFormat object has
a LibUnicode structure as a base. This is to prevent wild amounts of
code duplication between LibUnicode, Intl.DateTimeFormat, and other
not-yet-defined Intl structures, because there's 12 fields shared
between them.
For other keywords, allowed values per locale are generated at compile
time. But since the CLDR doesn't present hour cycles on a per-locale
basis, and hour cycles lookups depend on runtime data, we must handle
hour cycle keyword lookups differently than other keywords.
Unlike most data in the CLDR, hour cycles are not stored on a per-locale
basis. Instead, they are keyed by a string that is usually a region, but
sometimes is a locale. Therefore, given a locale, to determine the hour
cycles for that locale, we:
1. Check if the locale itself is assigned hour cycles.
2. If the locale has a region, check if that region is assigned hour
cycles.
3. Otherwise, maximize that locale, and if the maximized locale has
a region, check if that region is assigned hour cycles.
4. If the above all fail, fallback to the "001" region.
Further, each locale's default hour cycle is the first assigned hour
cycle.
Currently, we generate separate data files for locale and number format
related tables/methods, but provide public accessors for all of the data
in one Locale.h file. Rather than continuing this trend for date-time,
relative time, etc. formatting, it's a bit easier to reason about if the
public accessors are also in separate files.
Allocating a Vector for each of these invocations is a bit silly when
the values are basically all compile-time arrays. This AO is used even
more heavily by Intl.DateTimeFormat, so change it to accept a Span to
reduce its cost.
This also adds an overload to accept a fixed-size C-array so callers do
not have to be prefixed with AK::Array, i.e. this:
get_option(..., AK::Array { "a"sv, "b"sv }, ...);
Reduces to:
get_option(..., { "a"sv, "b"sv }, ...);
(Which is how all call sites were already written to construct a Vector
in place).
Gfx::Color implements an IPC::[en|de]code function, but we did not
actually link against LibIPC to resolve the needed Symbols for that and
were relying on LibGui or others to link against it for us.
Having this linkage is unfortunate, but static inlining the functions in
question is sadly not possible, due needed includes leading the IPC
pipeline to initialize multiple times then, which leads to a compilation
error.
Since AsyncIteratorClose and IteratorClose differ only in that the async
version awaits the inner value we just implement them with an enum flag
to switch just that behavior.
