Linus Groh
78724fdd33
LibJS: Don't accept UTC designators in strings for plain Temporal types
...
This is a normative change in the Temporal spec.
See: cd2dc7d
2021-11-24 08:56:03 +00:00
Linus Groh
836ce8ee5d
LibJS: Fix parse ErrorType used in parse_temporal_date_string()
...
TemporalInvalidDateString, not TemporalInvalidDateTimeString.
2021-11-24 08:38:50 +00:00
Linus Groh
0619c34703
LibJS: Implement Temporal.PlainDateTime.prototype.since()
2021-11-21 20:04:19 +00:00
Linus Groh
803eddbb62
LibJS: Implement Temporal.PlainDateTime.prototype.until()
2021-11-21 20:04:19 +00:00
Linus Groh
aed444253c
LibJS: Implement Temporal.PlainTime.prototype.since()
2021-11-21 20:04:19 +00:00
Linus Groh
2ac1774fd3
LibJS: Implement Temporal.PlainTime.prototype.until()
2021-11-21 20:04:19 +00:00
Linus Groh
783222f87a
LibJS: Implement parsing of TemporalInstantString
2021-11-20 23:10:09 +00:00
Linus Groh
79a18b058f
LibJS: Implement parsing of TemporalCalendarString
2021-11-20 23:10:09 +00:00
Linus Groh
1583c7257c
LibJS: Implement parsing of TemporalRelativeToString
2021-11-20 23:10:09 +00:00
Linus Groh
98b876ad3f
LibJS: Implement parsing of TemporalZonedDateTimeString
2021-11-20 23:10:09 +00:00
Linus Groh
3b1de431cc
LibJS: Implement parsing of TemporalYearMonthString
2021-11-20 23:10:09 +00:00
Linus Groh
3ddab2f4fe
LibJS: Implement parsing of TemporalMonthDayString
2021-11-20 23:10:09 +00:00
Linus Groh
453c78215c
LibJS: Implement parsing of TemporalTimeString
2021-11-20 23:10:09 +00:00
Linus Groh
b42b7d5f16
LibJS: Implement parsing of TemporalDateTimeString
2021-11-20 23:10:09 +00:00
Linus Groh
02e7de2cba
LibJS: Implement parsing of TemporalDateString
2021-11-20 23:10:09 +00:00
Linus Groh
d0c29c9735
LibJS: Allow string as parameter in Temporal's round() / total()
...
This is a normative change in the Temporal spec.
See: 1f0c586
2021-11-19 11:06:53 +00:00
Linus Groh
ec1e1f4f12
LibJS: Disallow Temporal.Duration input values to be non-integers
...
This is a normative change in the Temporal spec.
See: 8c85450
2021-11-17 22:20:59 +00:00
Luke Wilde
3666d2132b
LibJS: Remove fallback value for get_offset_nanoseconds_for
...
This is a normative change in the Temporal spec.
See: 664f02d
Note that the tests are not comprehensive.
2021-11-17 11:30:13 +00:00
Linus Groh
f1784c9c87
LibJS/Tests: Fix failing Array.prototype.toLocaleString() test
2021-11-17 10:00:20 +00:00
Timothy Flynn
39ab1a8999
LibJS: Implement ECMA-402 Array.prototype.toLocaleString
...
Turns out the only difference between our existing implementation and
the ECMA-402 implementation is we weren't passing the locales and
options list to each element.toLocaleString invocation.
This also adds spec comments to the definition.
2021-11-17 09:01:32 +00:00
Timothy Flynn
c19c3205ff
LibJS: Implement ECMA-402 Number.prototype.toLocaleString
2021-11-17 09:01:32 +00:00
Timothy Flynn
a1d5849e67
LibJS: Implement unit number formatting
2021-11-16 23:14:09 +00:00
Linus Groh
58c6a156bf
LibCrypto: Fix subtracting two negative SignedBigInteger
s
...
Currently, we get the following results
-1 - -2 = -1
-2 - -1 = 1
Correct would be:
-1 - -2 = 1
-2 - -1 = -1
This was already attempted to be fixed in 7ed8970
, but that change was
incorrect. This directly translates to LibJS BigInts having the same
incorrect behavior - it even was tested.
2021-11-16 10:06:53 +00:00
Luke Wilde
ac65fb40d9
LibJS: Implement Temporal.PlainDate.prototype.since
2021-11-16 01:06:07 +00:00
Luke Wilde
ddec3bc888
LibJS: Implement Temporal.PlainDate.prototype.until
2021-11-16 01:06:07 +00:00
Timothy Flynn
99c15741ba
LibJS: Conditionally ignore [[UseGrouping]] in compact notation
2021-11-16 00:56:55 +00:00
Timothy Flynn
fdae323401
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-16 00:56:55 +00:00
Timothy Flynn
4d79ab6866
LibJS: Implement engineering and scientific number formatting
2021-11-14 17:00:35 +00:00
Linus Groh
194d90dc72
LibJS: Don't coerce this value to object in Promise.prototype.finally()
2021-11-14 15:27:46 +00:00
Linus Groh
53ec432e8d
LibJS: Don't coerce this value to object in Promise.resolve()
2021-11-14 15:27:46 +00:00
Timothy Flynn
15c5fbd9e9
LibJS: Implement number grouping for Intl.NumberFormat
...
For example, in en-US, the number 123456 should be formatted as the
string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-14 10:35:19 +00:00
Luke Wilde
f6ab63993a
LibJS: Implement Temporal.ZonedDateTime.prototype.round
2021-11-13 19:48:54 +00:00
Timothy Flynn
3450def494
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 19:01:25 +00:00
Timothy Flynn
40973814e9
LibJS: Throw an exception in NumberFormat.prototype.format for BigInts
...
Rather than crashing in the call to as_double(), throw an exception for
now.
2021-11-13 19:01:25 +00:00
Linus Groh
dbe70e7c55
LibJS: Implement Temporal.Duration.prototype.total()
2021-11-13 18:50:54 +00:00
Linus Groh
f0cd727d74
LibJS: Fix logic typo in balance_duration() hours calculation
...
By using milliseconds_division_result instead of seconds_division_result
here, the result for hours was off by a factor of 60.
2021-11-13 13:32:35 +00:00
Timothy Flynn
a701ed52fc
LibJS+LibUnicode: Fully implement currency number formatting
...
Currencies are a bit strange; the layout of currency data in the CLDR is
not particularly compatible with what ECMA-402 expects. For example, the
currency format in the "en" and "ar" locales for the Latin script are:
en: "¤#,##0.00"
ar: "¤\u00A0#,##0.00"
Note how the "ar" locale has a non-breaking space after the currency
symbol (¤), but "en" does not. This does not mean that this space will
appear in the "ar"-formatted string, nor does it mean that a space won't
appear in the "en"-formatted string. This is a runtime decision based on
the currency display chosen by the user ("$" vs. "USD" vs. "US dollar")
and other rules in the Unicode TR-35 spec.
ECMA-402 shies away from the nuances here with "implementation-defined"
steps. LibUnicode will store the data parsed from the CLDR however it is
presented; making decisions about spacing, etc. will occur at runtime
based on user input.
2021-11-13 11:52:45 +00:00
Timothy Flynn
39e031c4dd
LibJS+LibUnicode: Generate all styles of currency localizations
...
Currently, LibUnicode is only parsing and generating the "long" style of
currency display names. However, the CLDR contains "short" and "narrow"
forms as well that need to be handled. Parse these, and update LibJS to
actually respect the "style" option provided by the user for displaying
currencies with Intl.DisplayNames.
Note: There are some discrepencies between the engines on how style is
handled. In particular, running:
new Intl.DisplayNames('en', {type:'currency', style:'narrow'}).of('usd')
Gives:
SpiderMoney: "USD"
V8: "US Dollar"
LibJS: "$"
And running:
new Intl.DisplayNames('en', {type:'currency', style:'short'}).of('usd')
Gives:
SpiderMonkey: "$"
V8: "US Dollar"
LibJS: "$"
My best guess is V8 isn't handling style, and just returning the long
form (which is what LibJS did before this commit). And SpiderMoney can
handle some styles, but if they don't have a value for the requested
style, they fall back to the canonicalized code passed into of().
2021-11-13 11:52:45 +00:00
Linus Groh
7f8dc395c1
LibJS: Implement Temporal.ZonedDateTime.prototype.with()
2021-11-13 00:25:40 +00:00
Linus Groh
a53542e0a3
LibJS: Clear exception after running each queued Promise job
...
It's not what the spec tells us to do. In fact, the spec tells us the
exact opposite:
9.5 Jobs and Host Operations to Enqueue Jobs
https://tc39.es/ecma262/#sec-jobs
A Job is an Abstract Closure with no parameters that initiates an
ECMAScript computation when no other ECMAScript computation is
currently in progress.
...
Their implementations must conform to the following requirements:
- ...
- The Abstract Closure must return a normal completion, implementing
its own handling of errors.
However, this turned out to not be true in all cases. More specifically,
the NewPromiseReactionJob AO returns the completion result of calling a
user-provided function (PromiseCapability's [[Resolve]] / [[Reject]]),
which may be an abrupt completion:
27.2.2.1 NewPromiseReactionJob ( reaction, argument )
https://tc39.es/ecma262/#sec-newpromisereactionjob
1. Let job be a new Job Abstract Closure with no parameters that
captures reaction and argument and performs the following steps
when called:
...
h. If handlerResult is an abrupt completion, then
i. Let status be Call(promiseCapability.[[Reject]],
undefined, « handlerResult.[[Value]] »).
i. Else,
i. Let status be Call(promiseCapability.[[Resolve]],
undefined, « handlerResult.[[Value]] »).
j. Return Completion(status).
Interestingly, this case is explicitly handled in the HTML spec's
implementation of jobs as microtasks:
8.1.5.3.3 HostEnqueuePromiseJob(job, realm)
https://html.spec.whatwg.org/webappapis.html#hostenqueuepromisejob
2. Queue a microtask on the surrounding agent's event loop to
perform the following steps:
...
5. If result is an abrupt completion, then report the exception
given by result.[[Value]].
This is precisely what all the major engines do - but not only in
browsers; the provided code snippet in the test added in this commit
works just fine in Node.js, for example.
SpiderMonkey:
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/builtin/Promise.cpp#6292
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/builtin/Promise.cpp#1277
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/vm/JSContext.cpp#845
JavaScriptCore:
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/builtins/PromiseOperations.js?rev=273718#L562
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/runtime/JSMicrotask.cpp?rev=273718#L94
V8:
https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/promise-abstract-operations.tq;l=481;drc=a760f03a6e99bf4863d8d21c5f7896a74a0a39ea
https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/builtins-microtask-queue-gen.cc;l=331;drc=65c9257f1777731d6d0669598f6fe6fe65fa61d3
This should probably be fixed in the ECMAScript spec to relax the rule
that Jobs may not return an abrupt completion, just like in the HTML
spec. The important bit is that those are not surfaced to user code in
any way.
2021-11-12 15:35:03 +02:00
Luke Wilde
f65d25682c
LibJS: Implement Temporal.ZonedDateTime.prototype.subtract
2021-11-12 09:24:36 +00:00
Luke Wilde
9b8524b463
LibJS: Implement Temporal.ZonedDateTime.prototype.add
2021-11-12 09:24:36 +00:00
Timothy Flynn
89523f70cf
LibJS: Begin implementing Intl.NumberFormat.prototype.format
...
There is quite a lot to be done here so this is just a first pass at
number formatting. Decimal and percent formatting are mostly working,
but only for standard and compact notation (engineering and scientific
notation are not implemented here). Currency formatting is parsed, but
there is more work to be done to handle e.g. using symbols instead of
currency codes ("$" instead of "USD"), and putting spaces around the
currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-12 09:17:08 +00:00
Luke Wilde
5e3fe52fc4
LibJS: Implement Temporal.Duration.compare
2021-11-11 21:06:54 +00:00
Luke Wilde
5594a492f0
LibJS: Implement Temporal.ZonedDateTime.prototype.toJSON
2021-11-10 12:56:56 +00:00
Luke Wilde
6856b6168a
LibJS: Implement Temporal.ZonedDateTime.prototype.toLocaleString
2021-11-10 12:56:56 +00:00
Luke Wilde
a9ad993e78
LibJS: Implement Temporal.ZonedDateTime.prototype.toString
2021-11-10 12:56:56 +00:00
Linus Groh
1e3e0477cb
LibJS: Implement Temporal.PlainMonthDay.prototype.with()
2021-11-08 22:19:45 +00:00
Linus Groh
fa1d5feec0
LibJS: Implement Temporal.PlainYearMonth.prototype.with()
2021-11-08 22:19:45 +00:00
Linus Groh
aca2ef9e1c
LibJS: Implement Temporal.PlainDateTime.prototype.with()
2021-11-08 22:19:45 +00:00