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

177 lines
8.3 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
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
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: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DECLARE_NATIVE_FUNCTION(name) \
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
static JS::Value name(JS::VM&, JS::GlobalObject&)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DECLARE_NATIVE_GETTER(name) \
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
static JS::Value name(JS::VM&, JS::GlobalObject&)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DECLARE_NATIVE_SETTER(name) \
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
static void name(JS::VM&, JS::GlobalObject&, JS::Value)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DEFINE_NATIVE_FUNCTION(name) \
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
JS::Value name([[maybe_unused]] JS::VM& vm, [[maybe_unused]] JS::GlobalObject& global_object)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DEFINE_NATIVE_GETTER(name) \
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
JS::Value name([[maybe_unused]] JS::VM& vm, [[maybe_unused]] JS::GlobalObject& global_object)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +00:00
#define JS_DEFINE_NATIVE_SETTER(name) \
Everywhere: Switch from (void) to [[maybe_unused]] (#4473) Problem: - `(void)` simply casts the expression to void. This is understood to indicate that it is ignored, but this is really a compiler trick to get the compiler to not generate a warning. Solution: - Use the `[[maybe_unused]]` attribute to indicate the value is unused. Note: - Functions taking a `(void)` argument list have also been changed to `()` because this is not needed and shows up in the same grep command.
2020-12-20 23:09:48 +00:00
void name([[maybe_unused]] JS::VM& vm, [[maybe_unused]] JS::GlobalObject& global_object, [[maybe_unused]] JS::Value value)
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 11:55:34 +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: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
#define JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES \
__JS_ENUMERATE(Array, array, ArrayPrototype, ArrayConstructor, void) \
__JS_ENUMERATE(ArrayBuffer, array_buffer, ArrayBufferPrototype, ArrayBufferConstructor, void) \
__JS_ENUMERATE(BigIntObject, bigint, BigIntPrototype, BigIntConstructor, void) \
__JS_ENUMERATE(BooleanObject, boolean, BooleanPrototype, BooleanConstructor, void) \
__JS_ENUMERATE(Date, date, DatePrototype, DateConstructor, void) \
__JS_ENUMERATE(Error, error, ErrorPrototype, ErrorConstructor, void) \
__JS_ENUMERATE(Function, function, FunctionPrototype, FunctionConstructor, void) \
__JS_ENUMERATE(NumberObject, number, NumberPrototype, NumberConstructor, void) \
__JS_ENUMERATE(Object, object, ObjectPrototype, ObjectConstructor, void) \
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
__JS_ENUMERATE(Promise, promise, PromisePrototype, PromiseConstructor, void) \
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
__JS_ENUMERATE(RegExpObject, regexp, RegExpPrototype, RegExpConstructor, void) \
LibJS: Add the Set built-in object
2021-06-08 21:08:47 +00:00
__JS_ENUMERATE(Set, set, SetPrototype, SetConstructor, void) \
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
__JS_ENUMERATE(StringObject, string, StringPrototype, StringConstructor, 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(SymbolObject, symbol, SymbolPrototype, SymbolConstructor, void)
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: 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_ERROR_SUBCLASSES \
__JS_ENUMERATE(EvalError, eval_error, EvalErrorPrototype, EvalErrorConstructor, void) \
__JS_ENUMERATE(InternalError, internal_error, InternalErrorPrototype, InternalErrorConstructor, void) \
__JS_ENUMERATE(InvalidCharacterError, invalid_character_error, InvalidCharacterErrorPrototype, InvalidCharacterErrorConstructor, 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) \
__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) \
__JS_ENUMERATE(Int8Array, int8_array, Int8ArrayPrototype, Int8ArrayConstructor, i8) \
__JS_ENUMERATE(Int16Array, int16_array, Int16ArrayPrototype, Int16ArrayConstructor, i16) \
__JS_ENUMERATE(Int32Array, int32_array, Int32ArrayPrototype, Int32ArrayConstructor, i32) \
__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
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 07:49:51 +00:00
#define JS_ENUMERATE_ITERATOR_PROTOTYPES \
__JS_ENUMERATE(Iterator, iterator) \
__JS_ENUMERATE(ArrayIterator, array_iterator) \
LibJS: Add the SetIterator built-in and Set.prototype.{values, entries} While this implementation should be complete it is based on HashTable's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashTable member in Set with an enhanced one that maintains a linked list in insertion order.
2021-06-08 21:17:17 +00:00
__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: 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_ERROR_SUBCLASSES \
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) \
__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: 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
#define JS_ENUMERATE_REGEXP_FLAGS \
__JS_ENUMERATE(global, global, g, Global) \
__JS_ENUMERATE(ignoreCase, ignore_case, i, Insensitive) \
__JS_ENUMERATE(multiline, multiline, m, Multiline) \
__JS_ENUMERATE(dotAll, dot_all, s, SingleLine) \
__JS_ENUMERATE(unicode, unicode, u, Unicode) \
__JS_ENUMERATE(sticky, sticky, y, Sticky)
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: Rename Allocator => CellAllocator Now that we have a BlockAllocator as well, it seems appropriate to name the allocator-that-allocates-cells something more specific to match.
2021-05-27 17:03:41 +00:00
class CellAllocator;
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: 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: Add DeferGC, a RAII way to prevent GC temporarily
2020-04-19 09:30:47 +00:00
class DeferGC;
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 "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
class Exception;
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: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 18:14:23 +00:00
class Accessor;
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: 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: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 19:58:22 +00:00
class LexicalEnvironment;
LibJS: Add MarkedValueList and use it for argument passing A MarkedValueList is basically a Vector<JS::Value> that registers with the Heap and makes sure that the stored values don't get GC'd. Before this change, we were unsafely keeping Vector<JS::Value> in some places, which is out-of-reach for the live reference finding logic since Vector puts its elements on the heap by default. We now pass all the JavaScript tests even when running with "js -g", which does a GC on every heap allocation.
2020-04-19 15:24:56 +00:00
class MarkedValueList;
LibJS: Add JS::NativeFunction to the forwarding header
2021-01-18 07:33:41 +00:00
class NativeFunction;
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 15:56:57 +00:00
class NativeProperty;
LibJS: Add a new PrimitiveString class to hold GC-allocated strings
2020-03-11 17:55:01 +00:00
class PrimitiveString;
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;
class PromiseReactionJob;
class PromiseResolveThenableJob;
LibJS: Implement the GetMethod abstract operation https://tc39.es/ecma262/#sec-getmethod We have bunch of duplicated on-demand versions of this, let's do it properly.
2021-03-02 17:04:13 +00:00
class PropertyName;
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 a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 15:02:27 +00:00
class ScopeObject;
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: 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+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: 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;
struct PromiseCapability;
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: 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+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
JS_ENUMERATE_ERROR_SUBCLASSES
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: 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: 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