Age | Commit message (Collapse) | Author |
|
We already did this but it called the @@iterator method of
%Array.prototype% visible to the user for example by overriding that
method. This should not be visible so we use a special version of
SuperCall now.
|
|
Although this already works in most cases in non-kvm serenity cases the
cosh and other math function tend to return incorrect values for
Infinity. This makes sure that whatever the underlying cosh function
returns Math.cosh conforms to the spec.
|
|
We cache on the AST node side as this is easier to track a position, we
just have to take care to wrap the values in a handle to make sure they
are not garbage collected.
|
|
Since tagged template literals can inspect the raw string it is not a
syntax error to have invalid escapes. However the cooked value should be
`undefined`.
We accomplish this by tracking whether parse_string_literal
fails and then using a NullLiteral (since UndefinedLiteral is not a
thing) and finally converting null in tagged template execution to
undefined.
|
|
We use strtod to convert a string to number after checking whether the
string is [+-]Infinity, however strtod also checks for either 'inf' or
'infinity' in a case-insensitive.
There are still valid cases for strtod to return infinity like 10e100000
so we just check if the "number" contains 'i' or 'I' in which case
the strtod infinity is not valid.
|
|
Assuming we had at least one argument meant that the ...arg count would
underflow causing the bound function to have length 0 instead of the
given length when binding with no arguments.
|
|
These sometimes produce different NaN patterns which can mess up the
value encoding.
|
|
20.2.3 Properties of the Function Prototype Object
https://tc39.es/ecma262/#sec-properties-of-the-function-prototype-object
The Function prototype object:
- is itself a built-in function object.
|
|
See https://github.com/tc39/ecma262/pull/2812.
|
|
This is a normative change in the ShadowRealm spec.
See: https://github.com/tc39/proposal-shadowrealm/commit/5a3aae8
|
|
This is a normative change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/2419680
|
|
This was removed from the change-array-by-copy proposal. See:
https://github.com/tc39/proposal-change-array-by-copy/commit/4c194d9
|
|
This is a normative change to the Intl NumberFormat V3 spec:
https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
|
|
This is a normative change to the Intl NumberFormat V3 spec:
https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
|
|
This is a normative change to the Intl spec:
https://github.com/tc39/ecma402/commit/769df4b
|
|
This isn't called out in TR-35, but before ICU even looks at CLDR data,
it adds a hard-coded set of default patterns to each locale's calendar.
It has done this since 2006 when its DateTimeFormat feature was first
created. Several test262 tests depend on this, which under ECMA-402,
falls into "implementation defined" behavior. For compatibility, we
can do the same in LibUnicode.
|
|
|
|
This is a normative change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/374305c
|
|
This is a normative change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/6f04074
|
|
|
|
Commit ec7d535 only partially handled the case of flexible day periods
rolling over midnight, in that it only worked for hours after midnight.
For example, the en locale defines a day period range of [21:00, 06:00).
The previous method of adding 24 hours to the given hour would change
e.g. 23:00 to 47:00, which isn't valid.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The largest exponents we compute are on the order of 10^21 (governed by
the maximumSignificantDigits option, which has a max value of 21). That
is too large to fit into the i64 we were using when multiplying this
exponent by the value to be formatted.
Instead, split up the logic to multiply that value by this exponent
based on the value's underlying type:
Number: Do not cast the result of pow() to an i64, and perform the
follow-up multiplication with doubles.
BigInt: Do not use pow(). Instead, compute the exponent as a BigInt
from the start, then perform the follow-up multiplication with that
BigInt.
|
|
For example, consider the locales "en-u-nu-fullwide" or "en-u-nu-arab".
The CLDR only declares the "latn" numbering system for the "en" locale,
thus ResolveLocale would change the locale to "en-u-nu-latn". This patch
allows using non-latn numbering systems digits.
|
|
Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to
only use the locale's signed pattern for negative numbers.
|
|
In the main spec, [[UseGrouping]] can be true or false. In V3, it may be
one of:
auto: Respect the per-locale preference for grouping.
always: Ignore per-locale preference for grouping and always insert
the grouping separator (note: true is now an alias for always).
min2: Ignore per-locale preference for grouping and only insert the
grouping separator if the primary group has at least 2 digits.
false: Ignore per-locale preference for grouping and never insert
the grouping separator.
|
|
This is inherited from Intl.NumberFormat.
|
|
This contains minimal changes to parse newly added and modified options
from the Intl.NumberFormat V3 proposal, while maintaining main spec
behavior in Intl.NumberFormat.prototype.format. The parsed options are
reflected only in Intl.NumberFormat.prototype.resolvedOptions and the js
REPL.
|
|
|
|
|
|
Previously we would treat the empty string as `null`. This caused
JavaScript like this to fail:
```js
var object = {};
try {
object = JSON.parse("");
} catch {}
var array = object.array || [];
```
Since `JSON.parse("")` returned null instead of throwing, it would set
`object` to null and then try and use it instead of using the default
backup value.
|
|
The Polish test cases added here cover previous failures from test262,
due to the way that 0 is specified to be "many" in Polish.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We do not yet parse collation data from the CLDR. This stubs out the
collations property, analogous to Intl.supportedValuesOf.
|
|
|
|
This is a manual but clean revert of all commits from #12595.
Adding a partial implementation of the resizable ArrayBuffer proposal
without implementing all the updates to TypedArray infrastructure that
is also covered by the spec introduced a bunch of crashes, so we
decided to revert it for now until a full implementation is completed.
|
|
It keeps failing on i686, and will until we've updated a bunch of size_t
APIs in the codebase to u64.
|
|
This aligns it with the spec again, it was clarified that the additional
range check before ArrayCreate is intentional:
https://github.com/tc39/proposal-change-array-by-copy/issues/94
Also cast the final variable to an u64 instead of size_t after we have
determined that it is safe to do so, as that's what Array::create()
takes now.
|