beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Userland/Libraries/LibJS/Forward.h

299 lines
15 KiB
C
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
/*
LibJS: Add ObjectEnvironmentRecord to Forward.h And sort the forward declared classes alphabetically, for our friends who enjoy alphabetically sorted things. :^)
2021-06-21 22:55:03 +00:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*/
#pragma once
LibJS: Let MarkedVector<T> inherit from Vector and handle Cell* + Value Note: MarkedVector is still relatively new and has zero users right now, so these changes don't affect any code other than the class itself. Reasons for this are the rather limited API: - Despite the name and unlike MarkedValueList, MarkedVector isn't actually a Vector, it *wraps* a Vector. This means that plenty of convenient APIs are unavailable and have to be exported on the class separately and forwarded to the internal Vector, or need to go through the exposed Span - both not great options. - Exposing append(Cell*) and prepend(Cell*) on the base class means that it was possible to append any Cell type, not just T! All the strong typing guarantees are basically gone, and MarkedVector doesn't do much more than casting Cells to the appropriate type through the exposed Span. All of this combined means that MarkedVector - in its current form - doesn't provide much value over MarkedValueList, and that we have to maintain two separate, yet almost identical classes. Let's fix this! The updated MarkedVector steals various concepts from the existing MarkedValueList, especially the ability to copy. On the other hand, it remains generic enough to handle both Cell* and Value for T, making MarkedValueList effectively redundant :^) Additionally, by inheriting from Vector we get all the current and future APIs without having to select and expose them separately. MarkedVectorBase remains and takes care of communicating creation and destruction of the class to the heap. Visiting the contained values is handled via a pure virtual method gather_roots(), which is being called by the Heap's function of the same name; much like the VM has one. From there, values are added to the roots HashTable if they are cells for T = Value, and unconditionally for any other T. As a small additional improvement the template now also takes an inline_capacity parameter, defaulting to 32, and forwards it to the Vector template; allowing for possible future optimizations of current uses of MarkedValueList, which hard-codes it to 32.
2022-02-09 09:40:49 +00:00
#include <AK/Types.h>
LibJS: Add ThrowCompletionOr versions of the JS native function macros The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all native functions were converted to the new format.
2021-10-19 17:18:01 +00:00
#define JS_DECLARE_NATIVE_FUNCTION(name) \
LibJS: Remove GlobalObject parameter from native functions
2022-08-22 10:48:08 +00:00
static JS::ThrowCompletionOr<JS::Value> name(JS::VM&)
LibJS: Add ThrowCompletionOr versions of the JS native function macros The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all native functions were converted to the new format.
2021-10-19 17:18:01 +00:00
#define JS_DEFINE_NATIVE_FUNCTION(name) \
LibJS: Remove GlobalObject parameter from native functions
2022-08-22 10:48:08 +00:00
JS::ThrowCompletionOr<JS::Value> name([[maybe_unused]] JS::VM& vm)
LibJS: Add ThrowCompletionOr versions of the JS native function macros The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all native functions were converted to the new format.
2021-10-19 17:18:01 +00:00
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
// NOTE: Proxy is not included here as it doesn't have a prototype - m_proxy_constructor is initialized separately.
LibJS: Parse async generator functions
2021-11-15 00:53:24 +00:00
#define JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES \
__JS_ENUMERATE(AggregateError, aggregate_error, AggregateErrorPrototype, AggregateErrorConstructor, void) \
__JS_ENUMERATE(Array, array, ArrayPrototype, ArrayConstructor, void) \
__JS_ENUMERATE(ArrayBuffer, array_buffer, ArrayBufferPrototype, ArrayBufferConstructor, void) \
__JS_ENUMERATE(AsyncFunction, async_function, AsyncFunctionPrototype, AsyncFunctionConstructor, void) \
__JS_ENUMERATE(AsyncGeneratorFunction, async_generator_function, AsyncGeneratorFunctionPrototype, AsyncGeneratorFunctionConstructor, void) \
__JS_ENUMERATE(BigIntObject, bigint, BigIntPrototype, BigIntConstructor, void) \
__JS_ENUMERATE(BooleanObject, boolean, BooleanPrototype, BooleanConstructor, void) \
__JS_ENUMERATE(DataView, data_view, DataViewPrototype, DataViewConstructor, void) \
__JS_ENUMERATE(Date, date, DatePrototype, DateConstructor, void) \
__JS_ENUMERATE(Error, error, ErrorPrototype, ErrorConstructor, void) \
__JS_ENUMERATE(FinalizationRegistry, finalization_registry, FinalizationRegistryPrototype, FinalizationRegistryConstructor, void) \
__JS_ENUMERATE(FunctionObject, function, FunctionPrototype, FunctionConstructor, void) \
__JS_ENUMERATE(GeneratorFunction, generator_function, GeneratorFunctionPrototype, GeneratorFunctionConstructor, void) \
__JS_ENUMERATE(Map, map, MapPrototype, MapConstructor, void) \
__JS_ENUMERATE(NumberObject, number, NumberPrototype, NumberConstructor, void) \
__JS_ENUMERATE(Object, object, ObjectPrototype, ObjectConstructor, void) \
__JS_ENUMERATE(Promise, promise, PromisePrototype, PromiseConstructor, void) \
__JS_ENUMERATE(RegExpObject, regexp, RegExpPrototype, RegExpConstructor, void) \
__JS_ENUMERATE(Set, set, SetPrototype, SetConstructor, void) \
__JS_ENUMERATE(ShadowRealm, shadow_realm, ShadowRealmPrototype, ShadowRealmConstructor, void) \
__JS_ENUMERATE(StringObject, string, StringPrototype, StringConstructor, void) \
__JS_ENUMERATE(SymbolObject, symbol, SymbolPrototype, SymbolConstructor, void) \
__JS_ENUMERATE(WeakMap, weak_map, WeakMapPrototype, WeakMapConstructor, void) \
__JS_ENUMERATE(WeakRef, weak_ref, WeakRefPrototype, WeakRefConstructor, void) \
LibJS: Add the WeakSet built-in object
2021-06-09 16:23:04 +00:00
__JS_ENUMERATE(WeakSet, weak_set, WeakSetPrototype, WeakSetConstructor, void)
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 20:05:25 +00:00
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
#define JS_ENUMERATE_NATIVE_OBJECTS \
JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES \
__JS_ENUMERATE(TypedArray, typed_array, TypedArrayPrototype, TypedArrayConstructor, void)
LibJS: Remove InvalidCharacterError This a Web API and not part of ECMA-262. Never has been.
2022-08-26 21:25:50 +00:00
#define JS_ENUMERATE_NATIVE_ERRORS \
__JS_ENUMERATE(EvalError, eval_error, EvalErrorPrototype, EvalErrorConstructor, void) \
__JS_ENUMERATE(InternalError, internal_error, InternalErrorPrototype, InternalErrorConstructor, void) \
__JS_ENUMERATE(RangeError, range_error, RangeErrorPrototype, RangeErrorConstructor, void) \
__JS_ENUMERATE(ReferenceError, reference_error, ReferenceErrorPrototype, ReferenceErrorConstructor, void) \
__JS_ENUMERATE(SyntaxError, syntax_error, SyntaxErrorPrototype, SyntaxErrorConstructor, void) \
__JS_ENUMERATE(TypeError, type_error, TypeErrorPrototype, TypeErrorConstructor, void) \
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 20:05:25 +00:00
__JS_ENUMERATE(URIError, uri_error, URIErrorPrototype, URIErrorConstructor, void)
LibJS+LibWeb: Make Uint8ClampedArray use TypedArray Instead of being its own separate unrelated class. This automatically makes typed array properties available to it, as well as making it available to the runtime.
2021-05-22 19:03:26 +00:00
#define JS_ENUMERATE_TYPED_ARRAYS \
__JS_ENUMERATE(Uint8Array, uint8_array, Uint8ArrayPrototype, Uint8ArrayConstructor, u8) \
__JS_ENUMERATE(Uint8ClampedArray, uint8_clamped_array, Uint8ClampedArrayPrototype, Uint8ClampedArrayConstructor, ClampedU8) \
__JS_ENUMERATE(Uint16Array, uint16_array, Uint16ArrayPrototype, Uint16ArrayConstructor, u16) \
__JS_ENUMERATE(Uint32Array, uint32_array, Uint32ArrayPrototype, Uint32ArrayConstructor, u32) \
LibJS: Add BigInt64Array and BigUint64Array This fixes ~297 test262 test cases :^)
2021-06-17 00:37:23 +00:00
__JS_ENUMERATE(BigUint64Array, big_uint64_array, BigUint64ArrayPrototype, BigUint64ArrayConstructor, u64) \
LibJS+LibWeb: Make Uint8ClampedArray use TypedArray Instead of being its own separate unrelated class. This automatically makes typed array properties available to it, as well as making it available to the runtime.
2021-05-22 19:03:26 +00:00
__JS_ENUMERATE(Int8Array, int8_array, Int8ArrayPrototype, Int8ArrayConstructor, i8) \
__JS_ENUMERATE(Int16Array, int16_array, Int16ArrayPrototype, Int16ArrayConstructor, i16) \
__JS_ENUMERATE(Int32Array, int32_array, Int32ArrayPrototype, Int32ArrayConstructor, i32) \
LibJS: Add BigInt64Array and BigUint64Array This fixes ~297 test262 test cases :^)
2021-06-17 00:37:23 +00:00
__JS_ENUMERATE(BigInt64Array, big_int64_array, BigInt64ArrayPrototype, BigInt64ArrayConstructor, i64) \
LibJS+LibWeb: Make Uint8ClampedArray use TypedArray Instead of being its own separate unrelated class. This automatically makes typed array properties available to it, as well as making it available to the runtime.
2021-05-22 19:03:26 +00:00
__JS_ENUMERATE(Float32Array, float32_array, Float32ArrayPrototype, Float32ArrayConstructor, float) \
LibJS: Add Float{32,64}Array
2020-12-05 22:28:10 +00:00
__JS_ENUMERATE(Float64Array, float64_array, Float64ArrayPrototype, Float64ArrayConstructor, double)
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 12:06:52 +00:00
LibJS: Start implementing Intl.Segmenter
2022-01-29 21:47:29 +00:00
#define JS_ENUMERATE_INTL_OBJECTS \
__JS_ENUMERATE(Collator, collator, CollatorPrototype, CollatorConstructor) \
__JS_ENUMERATE(DateTimeFormat, date_time_format, DateTimeFormatPrototype, DateTimeFormatConstructor) \
__JS_ENUMERATE(DisplayNames, display_names, DisplayNamesPrototype, DisplayNamesConstructor) \
LibJS: Start implementing the stage 3 Intl.DurationFormat proposal
2022-06-29 21:58:40 +00:00
__JS_ENUMERATE(DurationFormat, duration_format, DurationFormatPrototype, DurationFormatConstructor) \
LibJS: Start implementing Intl.Segmenter
2022-01-29 21:47:29 +00:00
__JS_ENUMERATE(ListFormat, list_format, ListFormatPrototype, ListFormatConstructor) \
__JS_ENUMERATE(Locale, locale, LocalePrototype, LocaleConstructor) \
__JS_ENUMERATE(NumberFormat, number_format, NumberFormatPrototype, NumberFormatConstructor) \
__JS_ENUMERATE(PluralRules, plural_rules, PluralRulesPrototype, PluralRulesConstructor) \
__JS_ENUMERATE(RelativeTimeFormat, relative_time_format, RelativeTimeFormatPrototype, RelativeTimeFormatConstructor) \
__JS_ENUMERATE(Segmenter, segmenter, SegmenterPrototype, SegmenterConstructor)
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 17:35:29 +00:00
LibJS: Start implementing Temporal.PlainYearMonth This commit adds the PlainYearMonth object itself, its constructor and prototype (currently empty), and the CreateTemporalYearMonth and ISOYearMonthWithinLimits abstract operations.
2021-08-07 21:40:32 +00:00
#define JS_ENUMERATE_TEMPORAL_OBJECTS \
__JS_ENUMERATE(Calendar, calendar, CalendarPrototype, CalendarConstructor) \
__JS_ENUMERATE(Duration, duration, DurationPrototype, DurationConstructor) \
__JS_ENUMERATE(Instant, instant, InstantPrototype, InstantConstructor) \
__JS_ENUMERATE(PlainDate, plain_date, PlainDatePrototype, PlainDateConstructor) \
__JS_ENUMERATE(PlainDateTime, plain_date_time, PlainDateTimePrototype, PlainDateTimeConstructor) \
LibJS: Start implementing Temporal.PlainMonthDay This commit adds the PlainMonthDay object itself, its constructor and prototype (currently empty), and the CreateTemporalMonthDay abstract operations.
2021-08-14 22:54:24 +00:00
__JS_ENUMERATE(PlainMonthDay, plain_month_day, PlainMonthDayPrototype, PlainMonthDayConstructor) \
LibJS: Start implementing Temporal.PlainYearMonth This commit adds the PlainYearMonth object itself, its constructor and prototype (currently empty), and the CreateTemporalYearMonth and ISOYearMonthWithinLimits abstract operations.
2021-08-07 21:40:32 +00:00
__JS_ENUMERATE(PlainTime, plain_time, PlainTimePrototype, PlainTimeConstructor) \
__JS_ENUMERATE(PlainYearMonth, plain_year_month, PlainYearMonthPrototype, PlainYearMonthConstructor) \
__JS_ENUMERATE(TimeZone, time_zone, TimeZonePrototype, TimeZoneConstructor) \
LibJS: Start implementing Temporal.ZonedDateTime This commit adds the ZonedDateTime object itself, its constructor and prototype (currently empty), and the CreateTemporalZonedDateTime abstract operation.
2021-08-01 16:20:11 +00:00
__JS_ENUMERATE(ZonedDateTime, zoned_date_time, ZonedDateTimePrototype, ZonedDateTimeConstructor)
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 19:39:55 +00:00
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
#define JS_ENUMERATE_BUILTIN_NAMESPACE_OBJECTS \
__JS_ENUMERATE(AtomicsObject, atomics) \
LibJS: Move ConsoleObject construction from GlobalObject to Intrinsics This will allow us to move the underlying console from GlobalObject to ConsoleObject without still having to do a 'console' property lookup on the GlobalObject.
2022-08-28 13:16:32 +00:00
__JS_ENUMERATE(ConsoleObject, console) \
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
__JS_ENUMERATE(Intl::Intl, intl) \
__JS_ENUMERATE(JSONObject, json) \
__JS_ENUMERATE(MathObject, math) \
__JS_ENUMERATE(ReflectObject, reflect) \
__JS_ENUMERATE(Temporal::Temporal, temporal)
LibJS: Implement the RegExpStringIterator object 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.
2021-07-15 12:58:27 +00:00
#define JS_ENUMERATE_ITERATOR_PROTOTYPES \
__JS_ENUMERATE(Iterator, iterator) \
__JS_ENUMERATE(ArrayIterator, array_iterator) \
LibJS: Add AsyncIteratorPrototype
2021-11-23 13:53:02 +00:00
__JS_ENUMERATE(AsyncIterator, async_iterator) \
LibJS: Start implementing Intl Segment Iterator objects
2022-01-30 00:18:47 +00:00
__JS_ENUMERATE(Intl::SegmentIterator, intl_segment_iterator) \
LibJS: Implement the RegExpStringIterator object 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.
2021-07-15 12:58:27 +00:00
__JS_ENUMERATE(MapIterator, map_iterator) \
__JS_ENUMERATE(RegExpStringIterator, regexp_string_iterator) \
__JS_ENUMERATE(SetIterator, set_iterator) \
LibJS: Add StringIterator
2020-07-12 03:23:01 +00:00
__JS_ENUMERATE(StringIterator, string_iterator)
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 21:58:20 +00:00
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 12:06:52 +00:00
#define JS_ENUMERATE_BUILTIN_TYPES \
JS_ENUMERATE_NATIVE_OBJECTS \
LibJS: Rename JS_ENUMERATE_{ERROR_SUBCLASSES => NATIVE_ERRORS} The fact that they *are* subclasses is an implementation detail and should not be highlighted. The spec calls these NativeErrors, so let's use that. Also added a comment explaining *why* they inherit from Error - I was about to change that :^)
2021-06-11 16:54:42 +00:00
JS_ENUMERATE_NATIVE_ERRORS \
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 20:05:25 +00:00
JS_ENUMERATE_TYPED_ARRAYS
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 10:42:33 +00:00
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 07:49:51 +00:00
#define JS_ENUMERATE_WELL_KNOWN_SYMBOLS \
__JS_ENUMERATE(iterator, iterator) \
__JS_ENUMERATE(asyncIterator, async_iterator) \
__JS_ENUMERATE(match, match) \
__JS_ENUMERATE(matchAll, match_all) \
__JS_ENUMERATE(replace, replace) \
LibJS: Implement most of String.prototype.replaceAll This also renames ErrorType::StringMatchAllNonGlobalRegExp to ErrorType::StringNonGlobalRegExp (removes "MatchAll") because this error is now used in the same way from multiple operations.
2021-07-01 20:28:33 +00:00
__JS_ENUMERATE(replaceAll, replace_all) \
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 07:49:51 +00:00
__JS_ENUMERATE(search, search) \
__JS_ENUMERATE(split, split) \
__JS_ENUMERATE(hasInstance, has_instance) \
__JS_ENUMERATE(isConcatSpreadable, is_concat_spreadable) \
__JS_ENUMERATE(unscopables, unscopables) \
__JS_ENUMERATE(species, species) \
__JS_ENUMERATE(toPrimitive, to_primitive) \
LibJS: Use macros to enumerate well-known symbols Not only is this a much nicer api (can't pass a typo'd string into the get_well_known_symbol function), it is also a bit more performant since there are no hashmap lookups.
2020-07-09 22:34:20 +00:00
__JS_ENUMERATE(toStringTag, to_string_tag)
LibJS: Hook up the 'v' (unicodeSets) RegExp flag
2022-07-16 05:44:03 +00:00
#define JS_ENUMERATE_REGEXP_FLAGS \
__JS_ENUMERATE(hasIndices, has_indices, d) \
__JS_ENUMERATE(global, global, g) \
__JS_ENUMERATE(ignoreCase, ignore_case, i) \
__JS_ENUMERATE(multiline, multiline, m) \
__JS_ENUMERATE(dotAll, dot_all, s) \
__JS_ENUMERATE(unicodeSets, unicode_sets, v) \
__JS_ENUMERATE(unicode, unicode, u) \
LibJS: Remove ECMAScriptFlags value from JS_ENUMERATE_REGEXP_FLAGS All regex flags supported by LibJS currently correspond to a LibRegex option, but this is not the case for the RegExp.prototype.hasIndices proposal, which is handled entirely in RegExpBuiltinExec. Remove the flag mapping to prepare for this. This incurs a bit of an optimization loss in the flag getters, as we now do a substring search, but we can revisit the getter implementation if it becomes an issue.
2021-07-09 19:39:43 +00:00
__JS_ENUMERATE(sticky, sticky, y)
LibJS: Make RegExp.prototype.flags spec-compliant This should be using the individual flag boolean properties rather than the [[OriginalFlags]] internal slot. Use an enumerator macro here for brevity, this will be useful for other things as well. :^)
2020-11-27 23:04:01 +00:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
namespace JS {
class ASTNode;
LibJS: Add ObjectEnvironmentRecord to Forward.h And sort the forward declared classes alphabetically, for our friends who enjoy alphabetically sorted things. :^)
2021-06-21 22:55:03 +00:00
class Accessor;
LibJS: Make AsyncGenerator not include AsyncGeneratorRequest.h
2022-11-23 10:44:43 +00:00
struct AsyncGeneratorRequest;
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
class BigInt;
LibJS: Implement Function.prototype.bind()
2020-04-19 20:03:02 +00:00
class BoundFunction;
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 18:23:58 +00:00
class Cell;
LibJS: Add ObjectEnvironmentRecord to Forward.h And sort the forward declared classes alphabetically, for our friends who enjoy alphabetically sorted things. :^)
2021-06-21 22:55:03 +00:00
class CellAllocator;
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 18:42:13 +00:00
class ClassExpression;
LibJS: De-duplicate ClassFieldDefinition Records This was defined twice, despite being the very same thing: - ClassElement::ClassFieldDefinition - ECMAScriptFunctionObject::InstanceField Move the former to a new header and use it everywhere. Also update the define_field() AO to take a single field instead of separate name and initializer arguments.
2022-04-19 22:06:45 +00:00
struct ClassFieldDefinition;
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 19:46:51 +00:00
class Completion;
LibJS: Move Console from Interpreter to GlobalObject Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29 19:15:06 +00:00
class Console;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class DeclarativeEnvironment;
LibJS: Add DeferGC, a RAII way to prevent GC temporarily
2020-04-19 09:30:47 +00:00
class DeferGC;
LibJS: Add ECMAScriptFunctionObject forward declaration
2021-09-24 22:02:04 +00:00
class ECMAScriptFunctionObject;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class Environment;
LibJS: Implement basic exception throwing You can now throw exceptions by calling Interpreter::throw_exception(). Anyone who calls ASTNode::execute() needs to check afterwards if the Interpreter now has an exception(), and if so, stop what they're doing and simply return. When catching an exception, we'll first execute the CatchClause node if present. After that, we'll execute the finalizer block if present. This is unlikely to be completely correct, but it's a start! :^)
2020-03-24 13:37:39 +00:00
class Error;
LibJS: Implement the CreateListFromArrayLike() abstract operation We already have two separate implementations of this, so let's do it properly. The optional value type check is done by a callback function that returns Result<void, ErrorType> - value type accepted or message for TypeError, that is.
2021-06-09 22:27:01 +00:00
class ErrorType;
LibWeb: Introduce the Environment Settings Object The environment settings object is effectively the context a piece of script is running under, for example, it contains the origin, responsible document, realm, global object and event loop for the current context. This effectively replaces ScriptExecutionContext, but it cannot be removed in this commit as EventTarget still depends on it. https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object
2021-10-14 15:12:53 +00:00
struct ExecutionContext;
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 11:16:51 +00:00
struct ExportEntry;
class ExportStatement;
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 18:27:43 +00:00
class Expression;
LibJS: Make Interpreter.h not include AST.h
2022-11-23 11:05:07 +00:00
class ForStatement;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class FunctionEnvironment;
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-09 22:49:23 +00:00
class FunctionNode;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class GlobalEnvironment;
LibJS: Add GlobalObject to the forwarding header
2020-04-01 19:04:42 +00:00
class GlobalObject;
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl*> and you can call JS::make_handle(T*) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed.
2020-03-18 19:03:17 +00:00
class HandleImpl;
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 18:23:58 +00:00
class Heap;
class HeapBlock;
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 11:16:51 +00:00
struct ImportEntry;
class ImportStatement;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
class Interpreter;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
class Intrinsics;
LibJS: Add ScriptOrModule to execution context and track it everywhere
2022-01-17 13:48:22 +00:00
class Module;
LibJS: Add JS::NativeFunction to the forwarding header
2021-01-18 07:33:41 +00:00
class NativeFunction;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class ObjectEnvironment;
LibJS: Make Parser::Error a standalone ParserError class This allows us to forward declare it and reduce the number of things that need to include Parser.h.
2022-11-23 11:39:23 +00:00
class Parser;
struct ParserError;
LibJS: Add a new PrimitiveString class to hold GC-allocated strings
2020-03-11 17:55:01 +00:00
class PrimitiveString;
LibJS: Make PromiseCapability GC-allocated A struct with three raw pointers to other GC'd types is a pretty big liability, let's just turn this into a Cell itself. This comes with the additional benefit of being able to capture it in a lambda effortlessly, without having to create handles for individual members.
2022-10-02 11:11:30 +00:00
class PromiseCapability;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 20:13:29 +00:00
class PromiseReaction;
LibJS: Add new PropertyDescriptor class and related abstract operations 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.
2021-07-03 21:57:21 +00:00
class PropertyAttributes;
class PropertyDescriptor;
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
class PropertyKey;
LibJS: Start adding a JS::Realm class (spec's "Realm Record")
2021-09-11 18:20:07 +00:00
class Realm;
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
class Reference;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
class ScopeNode;
LibJS: Add ScriptOrModule to execution context and track it everywhere
2022-01-17 13:48:22 +00:00
class Script;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 17:32:21 +00:00
class Shape;
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
class Statement;
LibJS: Replace StringOrSymbol::from_value with Value::to_property_key This is a more specification compliant implementation of the abstract operation 7.1.19 ToPropertyKey which should handle boxed symbols correctly.
2021-06-05 12:22:11 +00:00
class StringOrSymbol;
LibJS: Reduce AST memory usage by shrink-wrapping source range info Before this change, each AST node had a 64-byte SourceRange member. This SourceRange had the following layout: filename: StringView (16 bytes) start: Position (24 bytes) end: Position (24 bytes) The Position structs have { line, column, offset }, all members size_t. To reduce memory consumption, AST nodes now only store the following: source_code: NonnullRefPtr<SourceCode> (8 bytes) start_offset: u32 (4 bytes) end_offset: u32 (4 bytes) SourceCode is a new ref-counted data structure that keeps the filename and original parsed source code in a single location, and all AST nodes have a pointer to it. The start_offset and end_offset can be turned into (line, column) when necessary by calling SourceCode::range_from_offsets(). This will walk the source code string and compute line/column numbers on the fly, so it's not necessarily fast, but it should be rare since this information is primarily used for diagnostics and exception stack traces. With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a ~23% reduction in memory usage when loading twitter.com/awesomekling (330 MiB before, 253 MiB after!) :^)
2022-11-21 16:37:38 +00:00
class SourceCode;
struct SourceRange;
LibJS: Add host layering point related to modules to VM Also make HostResolveImportedModule fail on the browser to prevent module loading for now.
2022-01-18 18:14:25 +00:00
class SourceTextModule;
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-30 06:25:21 +00:00
class Symbol;
LibJS: Create JS to HTML markup generator The new JS::MarkupGenerator class can convert both a JS source string and a JS Runtime Value into properly formatted HTML using the new LibWeb System Palette css color values. It makes more sense for this JS -> HTML process to occur in LibJS so that it can be used elsewhere, namely Markdown code block syntax highlighting. It also means the Browser can worry less about LibJS implementation details.
2020-05-25 19:24:46 +00:00
class Token;
LibJS: Add a simple reference-counted UTF-16 string 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.
2021-08-09 12:58:31 +00:00
class Utf16String;
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 17:24:44 +00:00
class VM;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
class Value;
LibJS: Generify the garbage collector's weak container notifications This will allow us to use the same interface for other JS weak containers like the WeakMap & WeakRef.
2021-06-12 02:23:33 +00:00
class WeakContainer;
LibJS: Implement Wrapped Function Exotic Objects This is a new concept from the ShadowRealm API stage 3 proposal: https://tc39.es/proposal-shadowrealm/#sec-wrapped-function-exotic-objects
2021-10-13 20:08:48 +00:00
class WrappedFunction;
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
enum class DeclarationKind;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 20:13:29 +00:00
struct AlreadyResolved;
struct JobCallback;
LibJS: Add host layering point related to modules to VM Also make HostResolveImportedModule fail on the browser to prevent module loading for now.
2022-01-18 18:14:25 +00:00
struct ModuleRequest;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
class ProxyObject;
class ProxyConstructor;
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 14:01:35 +00:00
class AsyncFromSyncIteratorPrototype;
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 06:47:36 +00:00
class AsyncGenerator;
class AsyncGeneratorPrototype;
class GeneratorPrototype;
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
class TypedArrayConstructor;
class TypedArrayPrototype;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
class AtomicsObject;
LibJS: Move ConsoleObject construction from GlobalObject to Intrinsics This will allow us to move the underlying console from GlobalObject to ConsoleObject without still having to do a 'console' property lookup on the GlobalObject.
2022-08-28 13:16:32 +00:00
class ConsoleObject;
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
class JSONObject;
class MathObject;
class ReflectObject;
LibJS+LibWeb: Make Uint8ClampedArray use TypedArray Instead of being its own separate unrelated class. This automatically makes typed array properties available to it, as well as making it available to the runtime.
2021-05-22 19:03:26 +00:00
// Tag type used to differentiate between u8 as used by Uint8Array and u8 as used by Uint8ClampedArray.
struct ClampedU8;
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 20:05:25 +00:00
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName, ArrayType) \
class ClassName; \
class ConstructorName; \
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 12:06:52 +00:00
class PrototypeName;
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES
LibJS: Rename JS_ENUMERATE_{ERROR_SUBCLASSES => NATIVE_ERRORS} The fact that they *are* subclasses is an implementation detail and should not be highlighted. The spec calls these NativeErrors, so let's use that. Also added a comment explaining *why* they inherit from Error - I was about to change that :^)
2021-06-11 16:54:42 +00:00
JS_ENUMERATE_NATIVE_ERRORS
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
JS_ENUMERATE_TYPED_ARRAYS
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 12:06:52 +00:00
#undef __JS_ENUMERATE
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 10:42:33 +00:00
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
#define __JS_ENUMERATE(ClassName, snake_name) \
class ClassName; \
JS_ENUMERATE_BUILTIN_NAMESPACE_OBJECTS
#undef __JS_ENUMERATE
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 17:35:29 +00:00
namespace Intl {
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName) \
class ClassName; \
class ConstructorName; \
class PrototypeName;
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Start implementing Intl Segments objects
2022-01-29 23:08:42 +00:00
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
class Intl;
LibJS: Implement a basic Intl mathematical value The Intl mathematical value is much like ECMA-262's mathematical value in that it is meant to represent an arbitrarily precise number. The Intl MV further allows positive/negative infinity, negative zero, and NaN. This implementation is *not* arbitrarily precise. Rather, it is a replacement for the use of Value within Intl.NumberFormat. The exact syntax of the Intl MV is still being worked on, but abstracting this away into its own class will allow hooking in the finalized Intl MV more easily, and makes implementing Intl.NumberFormat.formatRange easier. Note the methods added here are essentially the same as the static helpers in Intl/NumberFormat.cpp.
2022-07-19 16:07:00 +00:00
class MathematicalValue;
LibJS: Start implementing Intl Segments objects
2022-01-29 23:08:42 +00:00
// Not included in JS_ENUMERATE_INTL_OBJECTS due to missing distinct constructor
class Segments;
class SegmentsPrototype;
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 17:35:29 +00:00
};
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 19:39:55 +00:00
namespace Temporal {
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName) \
class ClassName; \
class ConstructorName; \
class PrototypeName;
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
class Temporal;
LibJS: Describe various kinds of "Duration Records" This is an editorial change in the Temporal spec. See: https://github.com/tc39/proposal-temporal/commit/983902e We already had these defined as structs, but now they're properly defined in the spec (opposed to the previous anonymous records), and we don't have to make up our own names anymore :^) Note that while we're usually not including 'record' in the name, in this case the 'Duration Record' has a name clash with the Duration object. Additionally, later editorial changes introduce CreateFooRecord AOs, so let's just go with FooRecord structs here.
2022-03-09 21:59:17 +00:00
struct DurationRecord;
struct DateDurationRecord;
struct TimeDurationRecord;
struct PartialDurationRecord;
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 19:39:55 +00:00
};
LibJS: Add a JS::Completion class and JS::ThrowCompletionOr<T> template We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org>
2021-09-15 19:46:51 +00:00
template<typename T>
class ThrowCompletionOr;
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl*> and you can call JS::make_handle(T*) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed.
2020-03-18 19:03:17 +00:00
template<class T>
class Handle;
LibJS: Let MarkedVector<T> inherit from Vector and handle Cell* + Value Note: MarkedVector is still relatively new and has zero users right now, so these changes don't affect any code other than the class itself. Reasons for this are the rather limited API: - Despite the name and unlike MarkedValueList, MarkedVector isn't actually a Vector, it *wraps* a Vector. This means that plenty of convenient APIs are unavailable and have to be exported on the class separately and forwarded to the internal Vector, or need to go through the exposed Span - both not great options. - Exposing append(Cell*) and prepend(Cell*) on the base class means that it was possible to append any Cell type, not just T! All the strong typing guarantees are basically gone, and MarkedVector doesn't do much more than casting Cells to the appropriate type through the exposed Span. All of this combined means that MarkedVector - in its current form - doesn't provide much value over MarkedValueList, and that we have to maintain two separate, yet almost identical classes. Let's fix this! The updated MarkedVector steals various concepts from the existing MarkedValueList, especially the ability to copy. On the other hand, it remains generic enough to handle both Cell* and Value for T, making MarkedValueList effectively redundant :^) Additionally, by inheriting from Vector we get all the current and future APIs without having to select and expose them separately. MarkedVectorBase remains and takes care of communicating creation and destruction of the class to the heap. Visiting the contained values is handled via a pure virtual method gather_roots(), which is being called by the Heap's function of the same name; much like the VM has one. From there, values are added to the roots HashTable if they are cells for T = Value, and unconditionally for any other T. As a small additional improvement the template now also takes an inline_capacity parameter, defaulting to 32, and forwards it to the Vector template; allowing for possible future optimizations of current uses of MarkedValueList, which hard-codes it to 32.
2022-02-09 09:40:49 +00:00
template<class T, size_t inline_capacity = 32>
LibJS: Add MarkedVector<T> This abstracts a vector of Cell* with a strongly typed span() accessor that gives you Span<T*> instead of Span<Cell*>. It is intended to replace MarkedValueList in situations where you only need to store pointers to Cell (or an even more specific type of Cell). The API can definitely be improved, it's just the bare basics for now.
2021-12-16 17:54:06 +00:00
class MarkedVector;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
namespace Bytecode {
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 02:19:58 +00:00
class BasicBlock;
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 08:02:01 +00:00
struct Executable;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
class Generator;
class Instruction;
class Interpreter;
class Register;
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
}
Reference in a new issue Copy permalink