There's only two places where we're using the C99 feature of array
designated initalizers. This feature seemingly wasn't included with
C++20 designated initalizers for classes and structs. The only two
places we were using this feature are suitably old and isolated that
it makes sense to just suppress the warning at the usage sites while
discouraging future array designated intializers in new code.
Enable the warning project-wide. It catches when a non-virtual method
creates an overload set with a virtual method. This might cause
surprising overload resolution depending on how the method is invoked.
Before this patch, `which ""` or `type ""` would say that the empty
string is `/usr/local/bin/`.
Convert callers to consistently call is_empty() on the returned string
while we're at it, to support eventually removing the is_null() String
state in the future.
Certain C Libraries have (unfortunately) included strings.h as a
part of string.h, which violates the POSIX spec for that specific
header. Some applications rely on this being the case, so let's
include it in our string.h
This is another major milestone on our journey towards removing global
VM exception state :^)
Does pretty much exactly what it says on the tin: updating
ASTNode::execute() to return a Completion instead of a plain value. This
will *also* allow us to eventually remove the non-standard unwinding
mechanism and purely rely on the various completion types.
In the end this is a nicer API than having separate has_{value,target}()
and having to check those first, and then making another Optional from
the unwrapped value:
completion.has_value() ? completion.value() : Optional<Value> {}
// ^^^^^^^^^^^^^^^^^^
// Implicit creation of non-empty Optional<Value>
This way we need to unwrap the optional ourselves, but can easily pass
it to something else as well.
This is in anticipation of the AST using completions :^)
On account of row and column headers, when a user navigates to
a cell (for example in the spreadsheet application) that is
outside of the view, the cell is not properly aligned and so
is partially cut-off. This fix takes into account the row and
column headers when calculating the Rect to pass to the
scroll_into_view function.
ECMA-402 now supports short-offset, long-offset, short-generic, and
long-generic time zone name formatting. For example, in the en-US locale
the America/Eastern time zone would be formatted as:
short-offset: GMT-5
long-offset: GMT-05:00
short-generic: ET
long-generic: Eastern Time
We currently only support the UTC time zone, however. Therefore, this
very minimal implementation does not consider GMT offset or generic
display names. Instead, the CLDR defines specific strings for UTC.
Previously, FlacLoader would read the data for each frame into a
separate vector, which are then combined via extend() in the end. This
incurs an avoidable copy per frame. By having the next_frame() function
write into a given Span, there's only one vector allocated per call to
get_more_samples().
This increases performance by at least 100% realtime, as measured by
abench, from about 1200%-1300% to (usually) 1400% on complex test files.
It also needs to be able to take what the spec calls 'empty', which is
an Optional<Value> in this case (*not* an empty JS::Value). The common
use case is updating a completion with another completion, that may also
have an empty [[Value]] slot.
This is a normative change in the Intl spec:
https://github.com/tc39/ecma402/commit/f0f66cf
There are two main changes here:
1. Converting BigInt/Number objects to mathematical values.
2. A change in how ToRawPrecision computes its exponent and significant
digits.
For (1), we do not yet support BigInt number formatting, thus already
have coerced Number objects to a double. When BigInt is supported, the
number passed into these methods will likely still be a Value, thus can
be coereced then.
For (2), our implementation already returns the expected edge-case
results pointed out on the spec PR.
This is a normative change in the Intl spec:
https://github.com/tc39/ecma402/commit/f0f66cf
Our implementation is unaffected by this change. LibUnicode pre-computes
positive, negative, and signless format patterns, so we already format
negative infinity correctly. Also, the CLDR does not contain specific
locale-dependent strings for negative infinity anyways.
- Use umask() to prevent the parent process from tampering with the mode
bits of replacement passwd and shadow files.
- Use fchmod() to set new shadow files to mode 0600.
We should not expect LibC functions to clear `errno` on success,
so if we want to use it for error checking after a call, we need
to clear it before the call.
This means you can now do queries like:
```css
@media (400px <= width < 800px) { }
```
Chromium and Firefox which I tested with both don't support this yet, so
that's cool. :^)
Past me decided that the grammar was overly verbose and I could do it
better myself. Which seemed fine until the spec changed and I didn't
know how to integrate the changes. Lesson learned! :^)
Rather than have a function for every single part of the grammar, I have
written some as lambdas, and combned `<media-condition>` and
`<media-condition-without-or>` into one function. But otherwise it's
close to the spec, with comments listing the part of the grammar being
parsed, so hopefully it will be easier to make future adjustments!
This does not add any new functionality.
Web::CSS::MediaQuery::MediaFeature::Type was getting a bit ridiculous!
Also, this moves the detection of "min-" and "max-" media-features into
the MediaFeature itself, since this is an implementation detail, not
part of the spec.
Having these in here was a hack to support the other hack of making
media-queries use StyleValues. Now they don't do that, so we can remove
these again and keep things hygienic.
Previously, we were using StyleValues for this, which was a bit of a
hack and was brittle, breaking when I modified how custom properties
were parsed. This is better and also lets us limit the kinds of value
that can be used here, to match the spec.
Without this change, floor(-0.125) returned 0.
This is because the number has a fraction part even if mantissa is zero
while the unbiased exponent is negative.
The names of some variables were also made clearer.
Co-Authored-By: Daniel Bertalan <dani@danielbertalan.dev>
This was currently crashing Half-Life because it was a considered an
"Unknown" specifier. We can use the same case statement as the regular
hex format conversion (lower case 'x'), as the backend
to convert the number already supports upper/lower case input, hence
we get it for free :^)