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

299 lines
15 KiB
C
Raw Permalink 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
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2020-2021, Andreas Kling <andreas@ladybird.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: Explicitly disallow references in ThrowCompletionOr This will be disallowed by TRY soon, but the compile error produced by this requirement will pinpoint the errant line more accurately.
2023-01-13 20:45:04 +00:00
#include <AK/Concepts.h>
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) \
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack.
2022-12-21 10:48:14 +00:00
__JS_ENUMERATE(DisposableStack, disposable_stack, DisposableStackPrototype, DisposableStackConstructor, void) \
LibJS: Parse async generator functions
2021-11-15 00:53:24 +00:00
__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) \
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 14:01:04 +00:00
__JS_ENUMERATE(Iterator, iterator, IteratorPrototype, IteratorConstructor, void) \
LibJS: Parse async generator functions
2021-11-15 00:53:24 +00:00
__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) \
LibJS: Add initial implementation for SharedArrayBuffer None of the actual sharing is implemented yet, but this is enough for most basic functionality. Diff Tests: +260 ✅ -262 ❌ +2 💀
2023-07-01 04:07:26 +00:00
__JS_ENUMERATE(SharedArrayBuffer, shared_array_buffer, SharedArrayBufferPrototype, SharedArrayBufferConstructor, void) \
LibJS: Parse async generator functions
2021-11-15 00:53:24 +00:00
__JS_ENUMERATE(StringObject, string, StringPrototype, StringConstructor, void) \
LibJS: Add SuppressedError{, Prototype, Constructor}
2022-12-06 01:10:01 +00:00
__JS_ENUMERATE(SuppressedError, suppressed_error, SuppressedErrorPrototype, SuppressedErrorConstructor, void) \
LibJS: Parse async generator functions
2021-11-15 00:53:24 +00:00
__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: Add support for Float16Array Implements TC39 stage three proposal for Float16Arrays: https://tc39.es/proposal-float16array
2024-11-09 21:29:03 +00:00
__JS_ENUMERATE(Float16Array, float16_array, Float16ArrayPrototype, Float16ArrayConstructor, f16) \
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: Implement the Temporal.Duration constructor This also includes a stubbed Temporal.Duration.prototype. Until we have re-implemented Temporal.PlainDate/ZonedDateTime, some of Temporal.Duration.compare (and its invoked AOs) are left unimplemented.
2024-11-18 16:58:51 +00:00
#define JS_ENUMERATE_TEMPORAL_OBJECTS \
__JS_ENUMERATE(Duration, duration, DurationPrototype, DurationConstructor)
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(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 Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 13:39:33 +00:00
__JS_ENUMERATE(IteratorHelper, iterator_helper) \
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: Add Symbol.dispose
2022-12-20 18:26:02 +00:00
__JS_ENUMERATE(toStringTag, to_string_tag) \
__JS_ENUMERATE(dispose, dispose)
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
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 15:29:03 +00:00
#define JS_ENUMERATE_REGEXP_FLAGS \
__JS_ENUMERATE(HasIndices, hasIndices, has_indices, d) \
__JS_ENUMERATE(Global, global, global, g) \
__JS_ENUMERATE(IgnoreCase, ignoreCase, ignore_case, i) \
__JS_ENUMERATE(Multiline, multiline, multiline, m) \
__JS_ENUMERATE(DotAll, dotAll, dot_all, s) \
__JS_ENUMERATE(UnicodeSets, unicodeSets, unicode_sets, v) \
__JS_ENUMERATE(Unicode, unicode, unicode, u) \
__JS_ENUMERATE(Sticky, 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: Cache symbolicated stack frames on ExecutionContext Instead of re-symbolicating entire stacks from scratch every time we want a JS VM backtrace, we now use the ExecutionContext object as cache storage via a new CachedSourceRange object. This means that once a stack frame has been symbolicated, we don't have to resymbolicate it again (unless the program counter moves within that stack frame). This drastically reduces time spent in symbolication in some WPT tests.
2024-10-14 05:49:12 +00:00
struct CachedSourceRange;
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: 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+LibWeb: Another round of bringing module loading closer to spec In particular, this patch focuses on: - Updating the old "import assertions" to the new "import attributes" - Allowing realms as module import referrer
2023-12-02 15:20:01 +00:00
class CyclicModule;
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 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: Make FunctionNode::Parameter be a standalone FunctionParameter This will allow us to forward declare it and avoid including AST.h in a number of places.
2022-11-23 12:12:36 +00:00
struct FunctionParameter;
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+LibWeb: Another round of bringing module loading closer to spec In particular, this patch focuses on: - Updating the old "import assertions" to the new "import attributes" - Allowing realms as module import referrer
2023-12-02 15:20:01 +00:00
struct GraphLoadingState;
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: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 00:17:10 +00:00
class Identifier;
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: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 09:44:41 +00:00
class IteratorRecord;
LibJS: Forward declare the MemberExpression AST node
2023-07-06 21:01:03 +00:00
class MemberExpression;
LibJS+LibWeb: Make CyclicModule.h not include AST.h This led to some fallout as many things in LibJS and LibWeb were pulling in other things via CyclicModule.h
2022-11-23 12:28:01 +00:00
class MetaProperty;
LibJS: Add ScriptOrModule to execution context and track it everywhere
2022-01-17 13:48:22 +00:00
class Module;
LibJS+LibWeb: Move JS::ModuleRequest to its own header file This allows us to not include LibJS/AST.h in a couple more places.
2022-11-23 13:18:38 +00:00
struct ModuleRequest;
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 Script.h not include AST.h
2022-11-23 11:45:58 +00:00
class Program;
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: Cache access to properties found in prototype chain We already had fast access to own properties via shape-based IC. This patch extends the mechanism to properties on the prototype chain, using the "validity cell" technique from V8. - Prototype objects now have unique shape - Each prototype has an associated PrototypeChainValidity - When a prototype shape is mutated, every prototype shape "below" it in any prototype chain is invalidated. - Invalidation happens by marking the validity object as invalid, and then replacing it with a new validity object. - Property caches keep a pointer to the last seen valid validity. If there is no validity, or the validity is invalid, the cache misses and gets repopulated. This is very helpful when using JavaScript to access DOM objects, as we frequently have to traverse 4+ prototype objects before finding the property we're interested in on e.g EventTarget or Node.
2024-05-04 13:48:23 +00:00
class PrototypeChainValidity;
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: 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;
LibJS+LibWeb: Change JobCallback to be GC-allocated Fixes leak caused by mutual dependency when JS::Handle<JobCallback> is owned by GC-allocated PromiseReaction.
2024-03-12 02:49:13 +00:00
class 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: Add ModuleWithSpecifier for LoadedModules This patch adds ModuleWithSpecifier as the record type to be used in the LoadedModules field of Realm, Script and Cyclic Module Records.
2023-10-28 21:45:38 +00:00
struct ModuleWithSpecifier;
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: Implement Iterator.from and the WrapForValidIteratorPrototype Iterator.from creates an Iterator from either an existing iterator or an iterator-like object. In the latter case, it sets the prototype of the returned iterator to WrapForValidIteratorPrototype to wrap around the iterator-like object's iteration methods.
2023-06-24 15:27:30 +00:00
class WrapForValidIteratorPrototype;
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
LibWeb+Meta: Add wrapper for the BufferSource/ArrayBufferView IDL types These wrappers will make it much easier to do various operations on the different ArrayBuffer-related classes in LibWeb compared to the current solution, which is to just accept a Handle<Object> everywhere (and use "any" in the *.idl files). Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
2023-11-23 07:07:25 +00:00
class TypedArrayBase;
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: Remove our existing Temporal implementation Our Temporal implementation is woefully out of date. The spec has been so vastly rewritten that it is unfortunately not practical to update our implementation in-place. Even just removing Temporal objects that were removed from the spec, or updating any of the simpler remaining objects, has proven to be a mess in previous attempts. So, this removes our Temporal implementation. AOs used by other specs are left intact.
2024-11-16 17:51:53 +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 Temporal;
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>
LibJS: Explicitly disallow references in ThrowCompletionOr This will be disallowed by TRY soon, but the compile error produced by this requirement will pinpoint the errant line more accurately.
2023-01-13 20:45:04 +00:00
requires(!IsLvalueReference<T>)
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 ThrowCompletionOr;
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/Bytecode: Make StringTableIndex be a 32-bit index This makes a bunch of instructions smaller.
2024-05-10 05:12:45 +00:00
enum class Builtin : u8;
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 06:18:10 +00:00
class 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;
LibJS/Bytecode: Add Bytecode::Operand An Operand is either a register, a local, or a constant (index into the executable's constant table)
2024-02-02 09:19:17 +00:00
class Operand;
LibJS: Forward-declare RegexTable and BasicBlock in Executable.h Previously every file that included Executable.h (which is pretty much most LibJS and LibHTML files, given that VM.h needs it) had the whole definition of LibRegex, which was slowing down source parsing.
2023-10-08 10:25:58 +00:00
class RegexTable;
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 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