ladybird/Userland/Libraries/LibJS/Forward.h

244 lines
14 KiB
C
Raw Normal View History

/*
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#define JS_DECLARE_NATIVE_FUNCTION(name) \
static JS::ThrowCompletionOr<JS::Value> name(JS::VM&, JS::GlobalObject&)
#define JS_DEFINE_NATIVE_FUNCTION(name) \
JS::ThrowCompletionOr<JS::Value> name([[maybe_unused]] JS::VM& vm, [[maybe_unused]] JS::GlobalObject& global_object)
// NOTE: Proxy is not included here as it doesn't have a prototype - m_proxy_constructor is initialized separately.
2021-11-15 03:53:24 +03:00
#define JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES \
__JS_ENUMERATE(AggregateError, aggregate_error, AggregateErrorPrototype, AggregateErrorConstructor, void) \
__JS_ENUMERATE(Array, array, ArrayPrototype, ArrayConstructor, void) \
__JS_ENUMERATE(ArrayBuffer, array_buffer, ArrayBufferPrototype, ArrayBufferConstructor, void) \
__JS_ENUMERATE(AsyncFunction, async_function, AsyncFunctionPrototype, AsyncFunctionConstructor, void) \
__JS_ENUMERATE(AsyncGeneratorFunction, async_generator_function, AsyncGeneratorFunctionPrototype, AsyncGeneratorFunctionConstructor, void) \
__JS_ENUMERATE(BigIntObject, bigint, BigIntPrototype, BigIntConstructor, void) \
__JS_ENUMERATE(BooleanObject, boolean, BooleanPrototype, BooleanConstructor, void) \
__JS_ENUMERATE(DataView, data_view, DataViewPrototype, DataViewConstructor, void) \
__JS_ENUMERATE(Date, date, DatePrototype, DateConstructor, void) \
__JS_ENUMERATE(Error, error, ErrorPrototype, ErrorConstructor, void) \
__JS_ENUMERATE(FinalizationRegistry, finalization_registry, FinalizationRegistryPrototype, FinalizationRegistryConstructor, void) \
__JS_ENUMERATE(FunctionObject, function, FunctionPrototype, FunctionConstructor, void) \
__JS_ENUMERATE(GeneratorFunction, generator_function, GeneratorFunctionPrototype, GeneratorFunctionConstructor, void) \
__JS_ENUMERATE(Map, map, MapPrototype, MapConstructor, void) \
__JS_ENUMERATE(NumberObject, number, NumberPrototype, NumberConstructor, void) \
__JS_ENUMERATE(Object, object, ObjectPrototype, ObjectConstructor, void) \
__JS_ENUMERATE(Promise, promise, PromisePrototype, PromiseConstructor, void) \
__JS_ENUMERATE(RegExpObject, regexp, RegExpPrototype, RegExpConstructor, void) \
__JS_ENUMERATE(Set, set, SetPrototype, SetConstructor, void) \
__JS_ENUMERATE(ShadowRealm, shadow_realm, ShadowRealmPrototype, ShadowRealmConstructor, void) \
__JS_ENUMERATE(StringObject, string, StringPrototype, StringConstructor, void) \
__JS_ENUMERATE(SymbolObject, symbol, SymbolPrototype, SymbolConstructor, void) \
__JS_ENUMERATE(WeakMap, weak_map, WeakMapPrototype, WeakMapConstructor, void) \
__JS_ENUMERATE(WeakRef, weak_ref, WeakRefPrototype, WeakRefConstructor, void) \
2021-06-09 19:23:04 +03:00
__JS_ENUMERATE(WeakSet, weak_set, WeakSetPrototype, WeakSetConstructor, 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 03:23:40 +03:00
#define JS_ENUMERATE_NATIVE_OBJECTS \
JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES \
__JS_ENUMERATE(TypedArray, typed_array, TypedArrayPrototype, TypedArrayConstructor, void)
#define JS_ENUMERATE_NATIVE_ERRORS \
__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)
#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(BigUint64Array, big_uint64_array, BigUint64ArrayPrototype, BigUint64ArrayConstructor, u64) \
__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(BigInt64Array, big_int64_array, BigInt64ArrayPrototype, BigInt64ArrayConstructor, i64) \
__JS_ENUMERATE(Float32Array, float32_array, Float32ArrayPrototype, Float32ArrayConstructor, float) \
2020-12-06 01:28:10 +03:00
__JS_ENUMERATE(Float64Array, float64_array, Float64ArrayPrototype, Float64ArrayConstructor, double)
#define JS_ENUMERATE_INTL_OBJECTS \
__JS_ENUMERATE(DateTimeFormat, date_time_format, DateTimeFormatPrototype, DateTimeFormatConstructor) \
__JS_ENUMERATE(DisplayNames, display_names, DisplayNamesPrototype, DisplayNamesConstructor) \
__JS_ENUMERATE(ListFormat, list_format, ListFormatPrototype, ListFormatConstructor) \
__JS_ENUMERATE(Locale, locale, LocalePrototype, LocaleConstructor) \
__JS_ENUMERATE(NumberFormat, number_format, NumberFormatPrototype, NumberFormatConstructor)
#define JS_ENUMERATE_TEMPORAL_OBJECTS \
__JS_ENUMERATE(Calendar, calendar, CalendarPrototype, CalendarConstructor) \
__JS_ENUMERATE(Duration, duration, DurationPrototype, DurationConstructor) \
__JS_ENUMERATE(Instant, instant, InstantPrototype, InstantConstructor) \
__JS_ENUMERATE(PlainDate, plain_date, PlainDatePrototype, PlainDateConstructor) \
__JS_ENUMERATE(PlainDateTime, plain_date_time, PlainDateTimePrototype, PlainDateTimeConstructor) \
__JS_ENUMERATE(PlainMonthDay, plain_month_day, PlainMonthDayPrototype, PlainMonthDayConstructor) \
__JS_ENUMERATE(PlainTime, plain_time, PlainTimePrototype, PlainTimeConstructor) \
__JS_ENUMERATE(PlainYearMonth, plain_year_month, PlainYearMonthPrototype, PlainYearMonthConstructor) \
__JS_ENUMERATE(TimeZone, time_zone, TimeZonePrototype, TimeZoneConstructor) \
__JS_ENUMERATE(ZonedDateTime, zoned_date_time, ZonedDateTimePrototype, ZonedDateTimeConstructor)
#define JS_ENUMERATE_ITERATOR_PROTOTYPES \
__JS_ENUMERATE(Iterator, iterator) \
__JS_ENUMERATE(ArrayIterator, array_iterator) \
2021-11-23 16:53:02 +03:00
__JS_ENUMERATE(AsyncIterator, async_iterator) \
__JS_ENUMERATE(MapIterator, map_iterator) \
__JS_ENUMERATE(RegExpStringIterator, regexp_string_iterator) \
__JS_ENUMERATE(SetIterator, set_iterator) \
2020-07-12 06:23:01 +03:00
__JS_ENUMERATE(StringIterator, string_iterator)
#define JS_ENUMERATE_BUILTIN_TYPES \
JS_ENUMERATE_NATIVE_OBJECTS \
JS_ENUMERATE_NATIVE_ERRORS \
JS_ENUMERATE_TYPED_ARRAYS
#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(replaceAll, replace_all) \
__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) \
__JS_ENUMERATE(toStringTag, to_string_tag)
#define JS_ENUMERATE_REGEXP_FLAGS \
__JS_ENUMERATE(hasIndices, has_indices, d) \
__JS_ENUMERATE(global, global, g) \
__JS_ENUMERATE(ignoreCase, ignore_case, i) \
__JS_ENUMERATE(multiline, multiline, m) \
__JS_ENUMERATE(dotAll, dot_all, s) \
__JS_ENUMERATE(unicode, unicode, u) \
__JS_ENUMERATE(sticky, sticky, y)
namespace JS {
class ASTNode;
class Accessor;
2020-06-06 03:14:10 +03:00
class BigInt;
class BoundFunction;
class Cell;
class CellAllocator;
class ClassExpression;
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 22:46:51 +03:00
class Completion;
class Console;
class DeclarativeEnvironment;
class DeferGC;
class ECMAScriptFunctionObject;
class Environment;
class Error;
class ErrorType;
class Exception;
class Expression;
class FunctionEnvironment;
class FunctionNode;
class GlobalEnvironment;
class GlobalObject;
class HandleImpl;
class Heap;
class HeapBlock;
class Interpreter;
class MarkedValueList;
class NativeFunction;
class ObjectEnvironment;
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 23:13:29 +03:00
class PromiseReaction;
class PromiseReactionJob;
class PromiseResolveThenableJob;
class PropertyAttributes;
class PropertyDescriptor;
class PropertyKey;
class Realm;
class Reference;
class ScopeNode;
class Shape;
class Statement;
class StringOrSymbol;
class Symbol;
class Token;
class Utf16String;
class VM;
class Value;
class WeakContainer;
class WrappedFunction;
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 23:13:29 +03:00
struct AlreadyResolved;
struct JobCallback;
struct PromiseCapability;
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
class ProxyObject;
class ProxyConstructor;
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
class GeneratorObjectPrototype;
class AsyncFromSyncIteratorPrototype;
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 03:23:40 +03:00
class TypedArrayConstructor;
class TypedArrayPrototype;
// Tag type used to differentiate between u8 as used by Uint8Array and u8 as used by Uint8ClampedArray.
struct ClampedU8;
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName, ArrayType) \
class ClassName; \
class ConstructorName; \
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 03:23:40 +03:00
JS_ENUMERATE_NATIVE_OBJECTS_EXCLUDING_TEMPLATES
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 03:23:40 +03:00
JS_ENUMERATE_TYPED_ARRAYS
#undef __JS_ENUMERATE
namespace Intl {
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName) \
class ClassName; \
class ConstructorName; \
class PrototypeName;
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
};
namespace Temporal {
#define __JS_ENUMERATE(ClassName, snake_name, ConstructorName, PrototypeName) \
class ClassName; \
class ConstructorName; \
class PrototypeName;
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
struct TemporalDuration;
};
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 22:46:51 +03:00
template<typename T>
class ThrowCompletionOr;
template<class T>
class Handle;
template<class T>
class MarkedVector;
namespace Bytecode {
class BasicBlock;
struct Executable;
class Generator;
class Instruction;
class Interpreter;
class Register;
}
}