This would never return an empty optional or non-numeric value, and in
fact every caller as_double()'d the value right away.
Let's make the type match reality instead :^)
This will be needed by Value::to_string_without_side_effects, which can
be called in contexts without a VM (e.g. in AK::Format specializations).
So to_string_without_side_effects will need to be callable without a VM,
thus NumberToString must be as well.
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.
It's only used as a template parameter, so let it be forward-declared.
Otherwise, we aren't able to include Completion.h in Utf16String.h, as
there would be a Utf16String -> Completion -> Value -> Utf16String
include cycle.
These instances were detected by searching for files that include
AK/Concepts.h, but don't match the regex:
\\b(AnyString|Arithmetic|ArrayLike|DerivedFrom|Enum|FallibleFunction|Flo
atingPoint|Fundamental|HashCompatible|Indexable|Integral|IterableContain
er|IteratorFunction|IteratorPairWith|OneOf|OneOfIgnoringCV|SameAs|Signed
|SpecializationOf|Unsigned|VoidFunction)\\b
(Without the linebreaks.)
This regex is pessimistic, so there might be more files that don't
actually use any concepts.
In theory, one might use LibCPP to detect things like this
automatically, but let's do this one step after another.
This is an editorial change in the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/f660b14
Note that the explicit check for zero sign equality is no longer needed
as of b0d6399, which removed the ability of Crypto::SignedBigInteger to
represent negative zero.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Rename it to match the name used by the spec.
Add an override mode to skip formatting numbers with an exponential sign
(e.g. 1e23). This mode is needed by Number and Intl.NumberFormat, who
don't call out a specific number-to-string method to use (they just say
to make "the String consisting of the digits of n").
JS::Value stores 48 bit pointers to separately allocated objects in its
payload. On x86-64, canonical addresses have their top 16 bits set to
the same value as bit 47, effectively meaning that the value has to be
sign-extended to get the pointer. AArch64, however, expects the topmost
bits to be all zeros.
This commit gates sign extension behind `#if ARCH(X86_64)`, and adds an
`#error` for unsupported architectures, so that we do not forget to
think about pointer handling when porting to a new architecture.
Fixes#15290FixesSerenityOS/ladybird#56
For the fuzzer build isnan was not usable in a constexpr context however
__builtin_isnan seems to always be.
Also while we're here add my name to the copyright since I forgot after
the Value rewrite.
Using the fact that there are 2^52-2 NaN representations we can
"NaN-box" all the Values possible. This means that Value no longer has
an explicit "Type" but that information is now stored in the bits of a
double. This is done by "tagging" the top two bytes of the double.
For a full explanation see the large comment with asserts at the top of
Value.
We can also use the exact representation of the tags to make checking
properties like nullish, or is_cell quicker. But the largest gains are
in the fact that the size of a Value is now halved.
The SunSpider and other benchmarks have been ran to confirm that there
are no regressions in performance compared to the previous
implementation. The tests never performed worse and in some cases
performed better. But the biggest differences can be seen in memory
usage when large arrays are allocated. A simple test which allocates a
1000 arrays of size 100000 has roughly half the memory usage.
There is also space in the representations for future expansions such as
tuples and records.
To ensure that Values on the stack and registers are not lost during
garbage collection we also have to add a check to the Heap to check for
any of the cell tags and extracting the canonical form of the pointer
if it matches.
Values can be "empty" which only has a valid meaning for array holes.
We can however use this state the represent the empty state of an
Optional<Value> which is used in a lot of placed, because of Completion
having one.
This saves 8 bytes for every Optional<Value>.
This also allows constructing from other integral types like u64, which
would have been ambiguous before (at least on i686):
```
error: call of overloaded 'Value(u64&)' is ambiguous
note: candidate: 'JS::Value::Value(i32)'
175 | explicit Value(i32 value)
| ^~~~~
note: candidate: 'JS::Value::Value(unsigned int)'
164 | explicit Value(unsigned value)
| ^~~~~
note: candidate: 'JS::Value::Value(long unsigned int)'
153 | explicit Value(unsigned long value)
| ^~~~~
note: candidate: 'JS::Value::Value(double)'
141 | explicit Value(double value)
| ^~~~~
```
This change updates the parameter order of the is_less_than function
signature and calls to match accordingly with the spec
(https://tc39.es/ecma262/#sec-islessthan)
In many cases we already know a certain value is a number, or don't have
JS values at all and would need to wrap doubles in a value. To optimize
these cases and avoid having to pass a global object into functions that
won't ever allocate or throw, add a standalone implementation of this
function that takes and returns doubles directly.
This reverts commit 3a184f7841.
This broke a number of test262 tests under "TypedArrayConstructors".
The issue is that the CanonicalNumericIndexString AO should not fail
for inputs like "1.1", despite them not being integral indices.
When performing GetValue on a primitive type we do not need to perform
the ToObject conversion as it will resolve to a property on the
prototype object.
To avoid this we skip the initial ToObject conversion on the base value
as it only serves to get the primitive's boxed prototype. We further
specialize on PrimitiveString in order to get efficient behaviour
behaviour for the direct properties.
Depending on the tests anywhere from 20 to 60%, with significant loop
overhead.
The spec version of canonical_numeric_index_string is absurdly complex,
and ends up converting from a string to a number, and then back again
which is both slow and also requires a few allocations and a string
compare.
Instead lets use the logic we already have as that is much more
efficient.
This improves performance of all non-numeric property names.
The spec defines a StringToBigInt AO which allows for converting binary,
octal, decimal, and hexadecimal strings to a BigInt. Our conversion was
only allowing for decimal strings.
For example, say you try to create a Value from an Array and forgot to
include LibJS/Runtime/Array.h. This would cause the boolean constructor
to be used instead of a compile error.
This isn't a complete conversion to ErrorOr<void>, but a good chunk.
The end goal here is to propagate buffer allocation failures to the
caller, and allow the use of TRY() with formatting functions.
Instead of returning JS::StringOrSymbol, which is a space-optimized type
used in Shape property tables, this now returns JS::PropertyKey which is
*not* space-optimized, but has other niceties like optimized storage of
numeric ("indexed") properties.
