This adds plumbing for the Intl.DateTimeFormat object, constructor, and
prototype.
Note that unlike other Intl objects, the Intl.DateTimeFormat object has
a LibUnicode structure as a base. This is to prevent wild amounts of
code duplication between LibUnicode, Intl.DateTimeFormat, and other
not-yet-defined Intl structures, because there's 12 fields shared
between them.
This is the start of a parser for the ISO 8601 grammar used in the
Temporal spec:
https://tc39.es/proposal-temporal/#sec-temporal-iso8601grammar
We will, on purpose, not use a generic ISO 8601 parser from AK or
similar for two reasons:
- Many AOs make specific assumptions about which productions exist and
access them directly, even when they're part of a larger production.
- The spec says "The grammar deviates from the standard given in ISO
8601 in the following ways:" and then lists 17 of such deviations.
Making that work with a general purpose parser is not worth it.
The public API is not being used anywhere yet, but will be in the next
couple of commits. Likewise, the Production enum will be populated with
all the productions accessed directly (e.g. TemporalDateString).
Many thanks to Ali for showing me how to improve my initial approach
full of macros with a nice RAII helper - it's much nicer :^)
Co-Authored-By: Ali Mohammad Pur <mpfard@serenityos.org>
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").
This commit adds support for the most bare bones version of async
functions, support for async generator functions, async arrow functions
and await expressions are TODO.
This is a specialized string table for storing identifiers only.
Identifiers are always FlyStrings, which makes many common operations
faster by allowing O(1) comparison.
The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).
However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.
The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).
More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
There is notably FIXME notations in this commit regarding Unicode locale
extensions. We are not parsing extensions (or private use extensions) at
all yet.
The element-resolving functions on the Promise constructor are all very
similar. To prepare for more of these functions to be implemented, break
out common parts into a base class.
To help alleviate memory usage when creating and copying large strings,
create a simple wrapper around a Vector<u16> to reference count UTF-16
strings.
This is the start of implementing ECMA-402 in LibJS, better known as the
ECMAScript Internationalization API.
Much like Temporal this gets its own subdirectory (Runtime/Intl/) as
well as a new C++ namespace (JS::Intl) so we don't have to prefix all
the files and classes with "Intl".
https://tc39.es/ecma402/
This commit adds the PlainYearMonth object itself, its constructor and
prototype (currently empty), and the CreateTemporalYearMonth and
ISOYearMonthWithinLimits abstract operations.
This commit adds the ZonedDateTime object itself, its constructor and
prototype (currently empty), and the CreateTemporalZonedDateTime
abstract operation.
This implementation closely follows the StringIterator object in that
the abstract closure meant to be created in CreateRegExpStringIterator
is instead unrolled into RegExpStringIterator.prototype.next.
Just like the previous Temporal.{Instant,TimeZone} commits, this patch
adds the Calendar object itself, its constructor and prototype
(currently empty), and two required abstract operations.
This is Abstract Operation is required for the majority of
InstantConstructor's and InstantPrototype's methods.
The implementation is not entirely complete, (specifically 2 of the
underlying required abstract operations, ParseTemporalTimeZoneString
and ParseISODateTime are missing the required lexing, and as such are
TODO()-ed) but the majority of it is done.
These were an ad-hoc way to implement special behaviour when reading or
writing to specific object properties. Because these were effectively
replaced by the abillity to override the internal methods of Object,
they are no longer needed.
Just like the initial Temporal.TimeZone commit, this patch adds the
Instant object itself, its constructor and prototype (currently empty),
and two required abstract operations.
Here we got our first Temporal object :^)
This patch adds the TimeZone object itself, its constructor and
prototype (currently empty), and a bunch of required abstract operations
This will be home to various functions:
- Temporal.now.timeZone()
- Temporal.now.instant()
- Temporal.now.plainDateTime()
- Temporal.now.plainDateTimeISO()
- Temporal.now.zonedDateTime()
- Temporal.now.zonedDateTimeISO()
- Temporal.now.plainDate()
- Temporal.now.plainDateISO()
- Temporal.now.plainTimeISO()
Currently empty, but we gotta start somewhere! This is the start of
implementing the Temporal proposal (currently stage 3).
I have decided to start a new subdirectory (Runtime/Temporal/) as well
as a new C++ namespace (JS::Temporal) for this so we don't have to
prefix all the files and classes with "Temporal" - there will be a lot.
https://tc39.es/proposal-temporal/
This is a huge patch, I know. In hindsight this perhaps could've been
done slightly more incremental, but I started and then fixed everything
until it worked, and here we are. I tried splitting of some completely
unrelated changes into separate commits, however. Anyway.
This is a rewrite of most of Object, and by extension large parts of
Array, Proxy, Reflect, String, TypedArray, and some other things.
What we already had worked fine for about 90% of things, but getting the
last 10% right proved to be increasingly difficult with the current code
that sort of grew organically and is only very loosely based on the
spec - this became especially obvious when we started fixing a large
number of test262 failures.
Key changes include:
- 1:1 matching function names and parameters of all object-related
functions, to avoid ambiguity. Previously we had things like put(),
which the spec doesn't have - as a result it wasn't always clear which
need to be used.
- Better separation between object abstract operations and internal
methods - the former are always the same, the latter can be overridden
(and are therefore virtual). The internal methods (i.e. [[Foo]] in the
spec) are now prefixed with 'internal_' for clarity - again, it was
previously not always clear which AO a certain method represents,
get() could've been both Get and [[Get]] (I don't know which one it
was closer to right now).
Note that some of the old names have been kept until all code relying
on them is updated, but they are now simple wrappers around the
closest matching standard abstract operation.
- Simplifications of the storage layer: functions that write values to
storage are now prefixed with 'storage_' to make their purpose clear,
and as they are not part of the spec they should not contain any steps
specified by it. Much functionality is now covered by the layers above
it and was removed (e.g. handling of accessors, attribute checks).
- PropertyAttributes has been greatly simplified, and is being replaced
by PropertyDescriptor - a concept similar to the current
implementation, but more aligned with the actual spec. See the commit
message of the previous commit where it was introduced for details.
- As a bonus, and since I had to look at the spec a whole lot anyway, I
introduced more inline comments with the exact steps from the spec -
this makes it super easy to verify correctness.
- East-const all the things.
As a result of all of this, things are much more correct but a bit
slower now. Retaining speed wasn't a consideration at all, I have done
no profiling of the new code - there might be low hanging fruits, which
we can then harvest separately.
Special thanks to Idan for helping me with this by tracking down bugs,
updating everything outside of LibJS to work with these changes (LibWeb,
Spreadsheet, HackStudio), as well as providing countless patches to fix
regressions I introduced - there still are very few (we got it down to
5), but we also get many new passing test262 tests in return. :^)
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
This is an implementation of 'The Property Descriptor Specification
Type' and related abstract operations, namely:
- IsAccessorDescriptor
- IsDataDescriptor
- IsGenericDescriptor
- FromPropertyDescriptor
- ToPropertyDescriptor
- CompletePropertyDescriptor
It works with Optional<T> to enable omitting certain fields, which will
eventually replace the Attribute::Has{Getter,Setter,Configurable,
Enumerable,Writable} bit flags, which are awkward to work with - being
able to use an initializer list with any of the possible attributes is
much more convenient.
Parts of the current PropertyAttributes implementation as well as the
much simpler PropertyDescriptor struct in Object.h will eventually be
replaced with this and completely go away.
Property storage will still use the PropertyAttributes bit flags, this
is for the layers above.
Note that this is currently guarded behind an #if 0 as if conflicts with
the existing PropertyDescriptor struct, but it's known to compile and
work just fine - I simply want to have this in a separate commit, the
primary object rewrite commit will be large enough as is.
