As noted in the prototype comments, this implementation becomes less
accurate as the precision approaches the limit of 100. For example:
(3).toPrecision(100)
Should result in "3." followed by 99 "0"s. However, due to the loss of
accuracy in the floating point computations, we currently result in
"2.9999999...".
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 :^)
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:
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:
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.
This matches the text of the spec, and is more correct since the
variable is being updated, not defined it.
See: 5ab1822
---
I also changed `test_year += 1` to `test_year++` for consistency with
step 11.c that has the same description.
The spec has a note stating that resolve binding will always return a
reference whose [[ReferencedName]] field is name. However this is not
correct as the underlying method GetIdentifierReference may throw on
env.HasBinding(name) thus it can throw. However, there are some
scenarios where it cannot throw because the reference is known to exist
in that case we use MUST with a comment.
The this value is only supposed to be set via the BindThisValue and
accessed via the GetThisBinding AOs, so exposing a direct getter/setter
would only lead to potentially non-spec-compliant behavior down the
line.
...for now - the reason being that the AST breaks 'completion bubbling'
and returns a plain Value, and code at the call site relies on the VM
having an exception set when converting the plain value back into a
completion.
Fixes#11301.
This implements:
- console.group()
- console.groupCollapsed()
- console.groupEnd()
In the Browser, we use `<details>` for the groups, which is not actually
implemented yet, so groups are always open.
In the REPL, groups are non-interactive, but still indent any output.
This looks weird since the console prompt and return values remain on
the far left, but this matches what Node does so it's probably fine. :^)
I expect `console.group()` is not used much outside of browsers.
The general idea when ENABLE_UNICODE_DATABASE_DOWNLOAD is OFF has been
that the Intl APIs will provide obviously incorrect results, but should
not crash. This regressed a bit with NumberFormat and DateTimeFormat.
Just like with integral and floating numbers, doing it manually is
error-prone: when we get a negative remainder, y has to be added to the
result to match the spec's modulo.
Solve this by just adding another (templated) overload to also permit
using the function for LibCrypto BigInts.
