| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is done internally by just calling the more modern sigtimedwait
syscall and then massaging the results to fit sigwait's interface.
|
|
This is implemented as a simple wrapper around sigtimedwait()
|
|
This includes a new Thread::Blocker called SignalBlocker which blocks
until a signal of a matching type is pending. The current Blocker
implementation in the Kernel is very complicated, but cleaning it up is
a different yak for a different day.
|
|
|
|
|
|
|
|
|
|
We can get rid of a `VERIFY` since we already do this in `Array::at()`.
Also move `::mipmap()` to the header file so it is inlined in
`Sampler2D`.
|
|
This function popped up in profiles.
|
|
We were working with (0, 0) being the top-left of the render target,
but `glScissor` documentation states that this should be the
bottom-left instead.
|
|
Its value is always set in the constructor.
|
|
|
|
As stated in the manual:
glDeleteTextures silently ignores 0's and names that do not
correspond to existing textures.
If we do not skip these 0 names, they end up as invalid free texture
names in our name allocator.
|
|
|
|
Their values should match the enum values as defined by the Khronos
Group.
|
|
These enums are used to indicate byte-alignment when reading from and
to textures. The `GL_UNPACK_ROW_LENGTH` value was reimplemented to
support overriding the source data row width.
|
|
|
|
This option is already enabled when building Lagom, so let's enable it
for the main build too. We will no longer be surprised by Lagom Clang
CI builds failing while everything compiles locally.
Furthermore, the stronger `-Wsuggest-override` warning is enabled in
this commit, which enforces the use of the `override` keyword in all
classes, not just those which already have some methods marked as
`override`. This works with both GCC and Clang.
|
|
There are 443 number system objects generated, each of which held an
array of number system symbols. Of those 443 arrays, only 39 are unique.
To uniquely store these, this change moves the generated NumericSymbol
enumeration to the public LibUnicode/NumberFormat.h header with a pre-
defined set of symbols that we need. This is to ensure the generated,
unique arrays are created in a known order with known symbols. While it
is unfortunate to no longer discover these symbols at generation time,
it does allow us to ignore unwanted symbols and perform less string-to-
enumeration conversions at lookup time.
|
|
This was not happening locally for me, neither when building Lagom on
Linux nor with the SerenityOS toolchain...
error: implicit conversion from ‘float’ to ‘double’ to match other
result of conditional [-Werror=double-promotion]
|
|
|
|
Being really close to Object.prototype.valueOf() name wise makes this
unnecessarily confusing - while it sometimes serves as the
implementation of a valueOf() function, it's an abstraction which the
spec doesn't have.
Use the appropriate getters to retrieve specific internal slots instead,
most commonly [[FooData]] from the primitive wrapper objects.
For the Object class specifically, use the Value(Object*) ctor instead.
|
|
Some locales do not define morning, night, etc. day period ranges.
TR-35 states they should fall back to the fixed day periods AM and PM.
Add a test case for the "as" locale, which is one such locale, to ensure
its AM/PM symbols are used.
|
|
For the test cases changed here, we now recognize "morning2" and
"afternoon2" from the CLDR, so the expected results now match the specs
and other engines.
|
|
|
|
Generate morning2, afternoon2, evening2, and night2 symbols.
|
|
In the CLDR, there aren't "night" values, there are "night1" & "night2"
values. This is for locales which use a different name for nighttime
depending on the hour. For example, the ja locale uses "夜" between the
hours of 19:00 and 23:00, and "夜中" between the hours of 23:00 and
04:00. Our CLDR parser is currently ignoring "night2", so this rename
is to prepare for that.
We could probably come up with better names, but in the end, the API in
LibUnicode will be such that outside callers won't even see Night1, etc.
|
|
See: https://github.com/whatwg/dom/commit/cfe2f1e
|
|
|
|
This fixes #11166
|
|
|
|
|
|
|
|
This allows us to see which custom properties apply to a given element,
which previously wasn't shown.
|
|
|
|
|
|
Now that LibUnicode generates these patterns, the AO steps to retrieve
them may be implemented.
|
|
In a future commit, the "part" view returned from FormatDateTimePattern
may be a view into a string that goes out of scope. Ensure the AO only
returns valid views. A similar approach is used in Intl.NumberFormat.
|
|
The fields of the generated elements must be in the same order as the
table here:
https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
Further, only one field from each group of fields is allowed.
|
|
|
|
Pattern skeletons are more or less the "key" of format patterns. Every
format pattern is assigned a skeleton. Interval patterns (which are not
yet parsed) are also assigned a skeleton - this is used to match them to
an "owning" format pattern. So we will use the skeleton generated here
to match format patterns at runtime with their available interval
patterns.
An alternative approach would be to append interval patterns directly to
their owning format pattern, but this has some draw backs:
1. Skeletons aren't totally unique. A skeleton may appear in both
the "dateFormats" and "availableFormats" objects, in which case
the same interval formats would be generated more than once.
2. Otherwise unique format patterns may only differ by the interval
patterns assigned to them. This would cause the UniqueStorage for
the format patterns to increase in size, impacting both compile
times and libunicode.so size.
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/665871e
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/513c05b
|
|
This will allow users of EditingEngine classes to determine current type
of EditingEngine (currently either vim or regular).
|
|
|
|
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
|
|
We now stop processing variables once a length of 16384 tokens is
reached. This is an arbitrary number, but should be far beyond what
anyone will reasonably use, and small enough to not crash.
|
|
|
