summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Tests
AgeCommit message (Collapse)Author
2022-08-20LibJS: Use a synthetic constructor if class with parent doesn't have onedavidot
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.
2022-08-20LibJS: Add special cases for Math.cosh and add spec commentsdavidot
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.
2022-08-17LibJS: Implement tagged literals evaluation like the specdavidot
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.
2022-08-17LibJS: Allow invalid string in tagged template literalsdavidot
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.
2022-08-17LibJS: Make StringToNumber case sensitive when falling back to strtoddavidot
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.
2022-08-17LibJS: Don't assume a this argument for function.prototype.binddavidot
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.
2022-08-15LibJS: Add extreme value tests for cos and sindavidot
These sometimes produce different NaN patterns which can mess up the value encoding.
2022-08-14LibJS: Make Function.prototype a callable function objectLinus Groh
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.
2022-08-03LibJS: Only coerce value once in BigInt constructordavidot
See https://github.com/tc39/ecma262/pull/2812.
2022-07-31LibJS: Implement & use the {Ordinary,PrepareFor}WrappedFunctionCall AOsLinus Groh
This is a normative change in the ShadowRealm spec. See: https://github.com/tc39/proposal-shadowrealm/commit/5a3aae8
2022-07-30LibJS: Support IANA legacy names in the Temporal ISO 8601 grammarLinus Groh
This is a normative change in the Temporal spec. See: https://github.com/tc39/proposal-temporal/commit/2419680
2022-07-27LibJS: Remove %TypedArray%.prototype.toSplicedTimothy Flynn
This was removed from the change-array-by-copy proposal. See: https://github.com/tc39/proposal-change-array-by-copy/commit/4c194d9
2022-07-26LibJS: Allow out-of-order plural ranges to be formattedTimothy Flynn
This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26LibJS: Allow out-of-order number ranges to be formattedTimothy Flynn
This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26LibJS: Allow out-of-order date ranges to be formattedTimothy Flynn
This is a normative change to the Intl spec: https://github.com/tc39/ecma402/commit/769df4b
2022-07-22LibJS+LibUnicode: Generate a set of default DateTimeFormat patternsTimothy Flynn
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.
2022-07-22LibJS: Add tests for %TypedArray%.prototype.withObinna Ikeh
2022-07-22LibJS: Check PlainMonthDay is in the ISO date time limits in creationLuke Wilde
This is a normative change in the Temporal spec. See: https://github.com/tc39/proposal-temporal/commit/374305c
2022-07-22LibJS: Disallow negative day lengths in ZonedDateTime.protoype.roundLuke Wilde
This is a normative change in the Temporal spec. See: https://github.com/tc39/proposal-temporal/commit/6f04074
2022-07-21LibJS: Selectively display DateTimeFormat day periods as noonTimothy Flynn
2022-07-21LibJS+LibUnicode: Handle flexible day periods on both sides of midnightTimothy Flynn
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.
2022-07-20LibJS: Implement Intl.NumberFormat.prototype.formatRangeToPartsTimothy Flynn
2022-07-20LibJS: Implement Intl.NumberFormat.prototype.formatRangeTimothy Flynn
2022-07-20LibJS: Hook up the 'v' (unicodeSets) RegExp flagAli Mohammad Pur
2022-07-18LibJS: Implement Intl.NumberFormat V3's [[RoundingIncrement]] changesTimothy Flynn
2022-07-18LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changesTimothy Flynn
2022-07-18LibJS: Implement Intl.NumberFormat V3's [[TrailingZeroDisplay]] changesTimothy Flynn
2022-07-18LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changesTimothy Flynn
2022-07-18LibJS: Prevent i64 overflow when computing large NumberFormat exponentsTimothy Flynn
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.
2022-07-15LibJS: Allow specifying keyword values not directly defined for a localeTimothy Flynn
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.
2022-07-13LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changesTimothy Flynn
Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-13LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changesTimothy Flynn
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.
2022-07-13LibJS: Populate roundingPriority in Intl.PluralRules.resolvedOptionsTimothy Flynn
This is inherited from Intl.NumberFormat.
2022-07-13LibJS+js: Parse new constructor options from Intl.NumberFormat V3Timothy Flynn
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.
2022-07-12LibJS: Add test case for %TypedArray%.prototype.toSplicedObinna Ikeh
2022-07-12LibJS: Implement Intl.PluralRules.prototype.selectRangeTimothy Flynn
2022-07-10AK: Treat empty string as invalid JSONLuke Wilde
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.
2022-07-08LibJS: Use Intl.PluralRules within Intl.RelativeFormatTimothy Flynn
The Polish test cases added here cover previous failures from test262, due to the way that 0 is specified to be "many" in Polish.
2022-07-08LibJS: Implement Intl.PluralRules.prototype.selectTimothy Flynn
2022-07-08LibJS: Populate pluralCategories in Intl.PluralRules.resolvedOptionsTimothy Flynn
2022-07-06LibJS: Implement Intl.Locale.prototype.weekInfo propertyTimothy Flynn
2022-07-06LibJS: Implement Intl.Locale.prototype.textInfo propertyTimothy Flynn
2022-07-06LibJS: Implement Intl.Locale.prototype.timeZones propertyTimothy Flynn
2022-07-06LibJS: Implement Intl.Locale.prototype.numberingSystems propertyTimothy Flynn
2022-07-06LibJS: Implement Intl.Locale.prototype.hourCycles propertyTimothy Flynn
2022-07-06LibJS: Partially implement Intl.Locale.prototype.collations propertyTimothy Flynn
We do not yet parse collation data from the CLDR. This stubs out the collations property, analogous to Intl.supportedValuesOf.
2022-07-06LibJS: Implement Intl.Locale.prototype.calendars propertyTimothy Flynn
2022-07-06LibJS: Revert partial resizable ArrayBuffer implementationLinus Groh
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.
2022-07-04LibJS/Tests: Disable one Array.prototype.toSpliced test for nowLinus Groh
It keeps failing on i686, and will until we've updated a bunch of size_t APIs in the codebase to u64.
2022-07-04LibJS: Let Array.prototype.toSpliced throw RangeError for len <= 2^53-1Linus Groh
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.