LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-20 01:37:39 +03:00
Code Issues Packages Projects Releases Wiki Activity
a9335eea1c
ladybird/Libraries/LibJS/Forward.h

139 lines
6.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 21:42:11 +03:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#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 14:55:34 +03: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 19:36:49 +03: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 14:55:34 +03: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 19:36:49 +03: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 14:55:34 +03: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 19:36:49 +03: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 14:55:34 +03: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 19:36:49 +03: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 14:55:34 +03: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 19:36:49 +03: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 14:55:34 +03:00
#define JS_DEFINE_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 19:36:49 +03:00
void name([[maybe_unused]] JS::VM& vm, [[maybe_unused]] JS::GlobalObject& global_object, 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 14:55:34 +03:00
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
#define JS_ENUMERATE_NATIVE_OBJECTS \
__JS_ENUMERATE(Array, array, ArrayPrototype, ArrayConstructor) \
LibJS: Add BigInt
2020-06-06 03:14:10 +03:00
__JS_ENUMERATE(BigIntObject, bigint, BigIntPrototype, BigIntConstructor) \
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
__JS_ENUMERATE(BooleanObject, boolean, BooleanPrototype, BooleanConstructor) \
__JS_ENUMERATE(Date, date, DatePrototype, DateConstructor) \
__JS_ENUMERATE(Error, error, ErrorPrototype, ErrorConstructor) \
__JS_ENUMERATE(Function, function, FunctionPrototype, FunctionConstructor) \
__JS_ENUMERATE(NumberObject, number, NumberPrototype, NumberConstructor) \
__JS_ENUMERATE(Object, object, ObjectPrototype, ObjectConstructor) \
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-04 00:34:52 +03:00
__JS_ENUMERATE(ProxyObject, proxy, ProxyPrototype, ProxyConstructor) \
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-04 02:05:49 +03:00
__JS_ENUMERATE(RegExpObject, regexp, RegExpPrototype, RegExpConstructor) \
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 09:25:21 +03:00
__JS_ENUMERATE(StringObject, string, StringPrototype, StringConstructor) \
__JS_ENUMERATE(SymbolObject, symbol, SymbolPrototype, SymbolConstructor)
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 10:49:51 +03:00
#define JS_ENUMERATE_ERROR_SUBCLASSES \
__JS_ENUMERATE(EvalError, eval_error, EvalErrorPrototype, EvalErrorConstructor) \
__JS_ENUMERATE(InternalError, internal_error, InternalErrorPrototype, InternalErrorConstructor) \
__JS_ENUMERATE(InvalidCharacterError, invalid_character_error, InvalidCharacterErrorPrototype, InvalidCharacterErrorConstructor) \
__JS_ENUMERATE(RangeError, range_error, RangeErrorPrototype, RangeErrorConstructor) \
__JS_ENUMERATE(ReferenceError, reference_error, ReferenceErrorPrototype, ReferenceErrorConstructor) \
__JS_ENUMERATE(SyntaxError, syntax_error, SyntaxErrorPrototype, SyntaxErrorConstructor) \
__JS_ENUMERATE(TypeError, type_error, TypeErrorPrototype, TypeErrorConstructor) \
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
__JS_ENUMERATE(URIError, uri_error, URIErrorPrototype, URIErrorConstructor)
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 10:49:51 +03:00
#define JS_ENUMERATE_ITERATOR_PROTOTYPES \
__JS_ENUMERATE(Iterator, iterator) \
__JS_ENUMERATE(ArrayIterator, array_iterator) \
LibJS: Add StringIterator
2020-07-12 06:23:01 +03: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-10 00:58:20 +03:00
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
#define JS_ENUMERATE_BUILTIN_TYPES \
JS_ENUMERATE_NATIVE_OBJECTS \
JS_ENUMERATE_ERROR_SUBCLASSES
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 13:42:33 +03:00
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 10:49:51 +03: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-10 01:34:20 +03:00
__JS_ENUMERATE(toStringTag, to_string_tag)
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 21:42:11 +03:00
namespace JS {
class ASTNode;
LibJS: Add BigInt
2020-06-06 03:14:10 +03:00
class BigInt;
LibJS: Implement Function.prototype.bind()
2020-04-19 23:03:02 +03: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 21:23:58 +03:00
class Cell;
LibJS: Add DeferGC, a RAII way to prevent GC temporarily
2020-04-19 12:30:47 +03: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 16:37:39 +03: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-25 00:03:50 +03: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 21:27:43 +03: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 21:14:23 +03:00
class Accessor;
LibJS: Add GlobalObject to the forwarding header
2020-04-01 22:04:42 +03: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 22:03:17 +03: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 21:23:58 +03: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 21:42:11 +03: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 22:58:22 +03: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 18:24:56 +03:00
class MarkedValueList;
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 18:56:57 +03:00
class NativeProperty;
LibJS: Add a new PrimitiveString class to hold GC-allocated strings
2020-03-11 20:55:01 +03:00
class PrimitiveString;
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 13:10:16 +03: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 21:42:11 +03:00
class ScopeNode;
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 20:32:21 +03: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 18:46:41 +03:00
class Statement;
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 09:25:21 +03: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 22:24:46 +03:00
class Token;
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-22 00:46:51 +03:00
class Uint8ClampedArray;
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 20:24:44 +03: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 21:42:11 +03: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 12:59:18 +03:00
enum class DeclarationKind;
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 21:42:11 +03:00
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 15:06:52 +03:00
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName) \
class ClassName; \
class ConstructorName; \
class PrototypeName;
JS_ENUMERATE_BUILTIN_TYPES
#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 13:42:33 +03:00
LibJS: Correctly forward declare "Argument" as a struct
2020-04-04 11:46:00 +03:00
struct Argument;
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 22:03:17 +03:00
template<class T>
class Handle;
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 21:42:11 +03:00
}
Reference in New Issue Copy Permalink