Depending on how this is invoked, the preprocessor may get confused when
pasting the VM parameter into this expression. For example, it trips up
on the JS REPL in cases such as:
TRY_OR_THROW_OOM(*g_vm, ...);
Not an issue currently, but while developing, it's easy to miss cases
where an infallible AK::StringBuilder method is still used. By making
this inheritance private, and explicitly pulling in base methods we
can safely use, we get extra help from the compiler to indicate such
mistakes immediately.
For example, consider cases where we want to propagate errors only in
specific instances:
auto result = read_data(); // something like ErrorOr<ByteBuffer>
if (result.is_error() && result.error().code() != EINTR)
continue;
auto bytes = TRY(result);
The TRY invocation will currently copy the byte buffer when the
expression (in this case, just a local variable) is stored into
_temporary_result.
This patch binds the expression to a reference to prevent such copies.
In less trival invocations (such as TRY(some_function()), this will
incur only temporary lifetime extensions, i.e. no functional change.
First, this adds an overload of PrimitiveString::create for StringView.
This overload will throw an OOM completion if creating a String fails.
This is not only a bit more convenient, but it also ensures at compile
time that all PrimitiveString::create(string_view) invocations will be
handled as String and OOM-aware.
Next, this wraps all invocations to PrimitiveString::create(string_view)
with MUST_OR_THROW_OOM.
A small PrimitiveString::create(DeprecatedFlyString) overload also had
to be added to disambiguate between the StringView and DeprecatedString
overloads.
This is a normative change in the Intl.NumberFormat V3 spec. See:
08f599b
Note that this didn't seem to actually affect our implementation. The
Unicode spec states:
https://www.unicode.org/reports/tr35/tr35-53/tr35-numbers.html#Plural_Ranges
"If there is no value for a <start,end> pair, the default result is end"
Therefore, our implementation did not have the behavior noted by the
issue this normative change addressed:
const pr = new Intl.PluralRules("en-US");
pr.selectRange(1, 1); // Is "other", should be "one"
Our implementation already returned "one" here because there is no such
<start=one, end=one> value in the CLDR for en-US. Thus, we already
returned the end value of "one".
This is an editorial change in the Intl.NumberFormat V3 spec. See:
c24b33e
Note our implementation was already using the Intl MV in these AOs just
due to C++ type safety.
This is a normative change in the Intl.NumberFormat V3 spec. See:
23e69cf
This isn't particularly testable because every locale in the CLDR has a
non-empty "approximatelySign" field in cldr-numbers-modern. The issue
for this change seems to be considering the "miscPatterns/approximately"
field instead, which has different semantics. But as noted on the CLDR
issue https://unicode-org.atlassian.net/browse/CLDR-14918, the ICU uses
the "approximatelySign" field (as do our implementation).
This is a normative change in the Intl.NumberFormat V3 spec. See:
29acfc6
This is to allow Intl.PluralRules to use these options, as they were in-
effect required by later AOs anyways.
This is to allow using this macro in contexts that have defined `is`
already. For example, in ObjectConstructor, there is a native function
`is` which would trip up the compiler without this change.
This should solely be used to ignore completions from Heap::allocate in
currently-infallible contexts. It's mostly meant to let us both ignore
these errors and mark them with a FIXME in one go.
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
The goal here is to allow Cell::initialize to return a ThrowCompletion,
to handle OOM for example. Cell.h will then need to include Completion.h
which must include Value.h. This currently can't happen because Value.h
includes BigInt.h, which in turn includes Cell.h. So we would have an
include cycle.
This removes BigInt.h from Value.h, as it is forward-declarable (it is
only referred to with a reference or pointer). Then the Value overload
for Cell::Visitor::visit is moved to Cell.h, and missing BigInt.h
includes as peppered as needed.
Variables that are constexpr must be delcared inline in the global
namespace to prevent copying them.
The static keyword is meaningless on variables in headers in the global
namespace. Declare the static bigint as extern and define it out-of-line
instead.
Having an alias function that only wraps another one is silly, and
keeping the more obvious name should flush out more uses of deprecated
strings.
No behavior change.
