Currently, the UnicodeLocale generator collects a list of known locales
from the CLDR before processing language display names. For each locale,
the identifier is broken into language, script, and region subtags, and
we create a list of seen languages. When processing display names, we
skip languages we hadn't seen in that first step.
This is insufficient for language display names like "en-GB", which do
not have an locale entry in the CLDR, and thus are skipped. So instead,
create the list of known languages by actually reading through the list
of languages which have a display name.
These patterns indicate how to display locale strings when that locale
contains multiple subtags. For example, "en-US" would be displayed as
"English (United States)".
The two Adler32 checksums are u16 and these two getters were mistakenly
left as u32 when PNGChunk::add_as_big_endian() was templated leading
to corrupted IDAT fields in our PNGs.
This is supposed to work as follows (grabbed from SpiderMonkey):
> opt = { type: "language", languageDisplay: "dialect" };
> new Intl.DisplayNames([], opt).of("en-US");
"American English"
> opt = { type: "language", languageDisplay: "standard" };
> new Intl.DisplayNames([], opt).of("en-US");
"English (United States)"
We currently display the "dialect" variant. We will need to figure out
how to display the "standard" variant. I think the way it works is that
we take the display names of "en" (language) and "US" (region) and
format them according to this pattern in localeDisplayNames.json:
"localeDisplayNames": {
"localeDisplayPattern": {
"localePattern": "{0} ({1})",
},
},
But I'd like to confirm this before implementing it.
Before LibUnicode generated methods were weakly linked, we had a public
method (get_locale_currency_mapping) for retrieving currency mappings.
That method invoked one of several style-specific methods that only
existed in the generated UnicodeLocale.
One caveat of weakly linked functions is that every such function must
have a public declaration. The result is that each of those styled
methods are declared publicly, which makes the wrapper redundant
because it is just as easy to invoke the method for the desired style.
Note there's a bit of an unfortunate duplication in the calendar enum
generated by UnicodeLocale and the existing enum generated by
UnicodeDateTimeFormat. The former contains every calendar known to the
CLDR, whereas the latter contains the calendars we've actually parsed
for DateTimeFormat (currently only Gregorian). The new enum generated
here can be removed once DateTimeFormat knows about all calendars.
Intl.DisplayNames v2 adds "calendar" and "dateTimeField" types, as well
as a "languageDisplay" option for the "language" type. This just adds
these options to the constructor.
You now cannot get an unconnected LibIMAP::Client, but you can still
close it. This makes for a nicer API where we don't have a Client object
in a limbo state between being constructed and being connected.
This code still isn't as nice as it should be, as TLS::TLSv12 is still
not a Core::Stream::Socket subclass, which would allow for consolidating
most of the TLS/non-TLS code into a single implementation.
As per previous discussion, it was decided that the Stream classes
should be constructed on the heap.
While I don't personally agree with this change, it does have the
benefit of avoiding Function object reconstructions due to the lambda
passed to Notifier pointing to a stale object reference. This also has
the benefit of not having to "box" objects for virtual usage, as the
objects come pre-boxed.
However, it means that we now hit the heap everytime we construct a
TCPSocket for instance, which might not be desirable.
SocketError is a relic from the KResult days when we couldn't have a
string in the KResult type, only an errno. Now that we can use string
literals with Error, it's no longer necessary. gai_strerror is thread
safe, so we can use it here unlike strerror.
When `GL_COLOR_MATERIAL` is enabled, specific material parameters can
be overwritten by the current color per-vertex during the lighting
calculations. Which parameter is controlled by `glColorMaterial`.
Also move the lighting calculations _before_ clipping, because the spec
says so. As a result, we interpolate the resulting vertex color instead
of the input color.
Required by Xash3D for the r_showtextures command, where it shows every
allocated texture on screen.
Description of glIsTexture from the spec:
"glIsTexture returns GL_TRUE if texture is currently the name of a
texture. If texture is zero, or is a non-zero value that is not
currently the name of a texture, or if an error occurs, glIsTexture
returns GL_FALSE.
A name returned by glGenTextures, but not yet associated with a texture
by calling glBindTexture, is not the name of a texture."
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glIsTexture.xhtml
Required by Xash3D, which forgoes glGenTexture and implements its own
texture generator. It expects glBindTexture to pick up on this though.
The strategy here is to keep texture_object null if we don't find the
texture in the allocation textures map, as it will then both generate
and set the texture in the allocated textures map using the texture
name passed to us, then bind it.
Xash3D requires this otherwise it will crash with a jump to nullptr,
but it doesn't use it for anything interesting and just sets a default
value of ~0 during initialization.
No need to take the spec literally here since we know the input values
are guaranteed to be integral numbers. Use AK string to number parsing
functionality instead and save a couple of PrimitiveString allocations.
This matches what we already do in parse_temporal_time_zone_string().
Two issues:
- The intended range was 9 characters starting from index 1. Since the
second argument to String::substring() is the length, 10 is
potentially reading further than the string's length (when only
providing one fraction digit), causing an assertion failure crash.
- The spec's intention to skip the decimal separator by starting at
index 1 is incorrect, no decimal separator is present in the result of
parsing TimeZoneUTCOffsetFractionalPart. I filed a spec fix for this,
see: https://github.com/tc39/proposal-temporal/pull/1999
As all variables and numeric literals in the expression have an integral
data type, it would evaluate to an int and could easily overflow as
we're multiplying seconds with 10^9.
Introduce a floating point literal into the expression to make it result
in a double.
A sign that's either the value 1 or -1 should obviously not have an
unsigned data type :^)
This would cause it to become 255 for the negative offset case, which
would then completely screw up the offset_nanoseconds calculation as it
serves as a multiplier.
If a thumbnail cannot load it's a good opportunity to print out the
error message.
On top of that, we still want to update m_thumbnail_progress so that
the progress bar doesn't get stuck instead of returning early from
the lambda.
Previously, Core::command only returned a String which contained the
data from stdout.
The CommandResult struct contains the exit code as well as the data
from stdout and stderr.
According to the OpenGL spec, invoking functions without an active
context results in undefined behavior. Since ScummVM seems to be the
only port having issues with our behavior, patch their code instead.
We don't mutate the pointed-to memory, so let's be const correct.
Fixes building the `mimalloc` library that's optionally used by the mold
linker (note that it isn't enabled yet as I haven't tested it).
This function is an extended version of `chmod(2)` that lets one control
whether to dereference symlinks, and specify a file descriptor to a
directory that will be used as the base for relative paths.
If there's less than 3 vertices, we cannot do triangle strip otherwise
we will go out-of-bounds of the vertices vector.
Required for Half-Life, which sometimes submits 0 vertices for triangle
strip when drawing the electric disks around the pillars in Xen.
