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/Libraries/LibJS/Runtime/GeneratorFunctionConstructor.cpp

55 lines
2.1 KiB
C++
Raw Permalink Normal View History

LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
/*
* Copyright (c) 2021, Matthew Olsson <mattco@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 20:40:38 +00:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
#include <LibJS/Runtime/FunctionConstructor.h>
#include <LibJS/Runtime/GeneratorFunctionConstructor.h>
#include <LibJS/Runtime/GlobalObject.h>
namespace JS {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
GC_DEFINE_ALLOCATOR(GeneratorFunctionConstructor);
LibJS: Segregate GC-allocated objects by type This patch adds two macros to declare per-type allocators: - JS_DECLARE_ALLOCATOR(TypeName) - JS_DEFINE_ALLOCATOR(TypeName) When used, they add a type-specific CellAllocator that the Heap will delegate allocation requests to. The result of this is that GC objects of the same type always end up within the same HeapBlock, drastically reducing the ability to perform type confusion attacks. It also improves HeapBlock utilization, since each block now has cells sized exactly to the type used within that block. (Previously we only had a handful of block sizes available, and most GC allocations ended up with a large amount of slack in their tails.) There is a small performance hit from this, but I'm sure we can make up for it elsewhere. Note that the old size-based allocators still exist, and we fall back to them for any type that doesn't have its own CellAllocator.
2023-11-19 08:45:05 +00:00
LibJS+LibWeb: Replace GlobalObject with Realm in object constructors No functional changes - we can still very easily get to the global object via `Realm::global_object()`. This is in preparation of moving the intrinsics to the realm and no longer having to pass a global object when allocating any object. In a few (now, and many more in subsequent commits) places we get a realm using `GlobalObject::associated_realm()`, this is intended to be temporary. For example, create() functions will later receive the same treatment and are passed a realm instead of a global object.
2022-08-15 23:20:49 +00:00
GeneratorFunctionConstructor::GeneratorFunctionConstructor(Realm& realm)
LibJS: Make intrinsics getters return NonnullGCPtr Some of these are allocated upon initialization of the intrinsics, and some lazily, but in neither case the getters actually return a nullptr. This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has an `operator T&()`), and also has the interesting side effect of forcing us to explicitly use the FunctionObject& overload of call(), as passing a NonnullGCPtr is ambigous - it could implicitly be turned into a Value _or_ a FunctionObject& (so we have to dereference manually).
2023-04-12 22:47:15 +00:00
: NativeFunction(static_cast<Object&>(realm.intrinsics().function_constructor()))
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
{
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
void GeneratorFunctionConstructor::initialize(Realm& realm)
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
{
auto& vm = this->vm();
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
Base::initialize(realm);
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
// 27.3.2.1 GeneratorFunction.length, https://tc39.es/ecma262/#sec-generatorfunction.length
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-05 23:15:08 +00:00
define_direct_property(vm.names.length, Value(1), Attribute::Configurable);
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
// 27.3.2.2 GeneratorFunction.prototype, https://tc39.es/ecma262/#sec-generatorfunction.length
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-26 23:54:55 +00:00
define_direct_property(vm.names.prototype, realm.intrinsics().generator_function_prototype(), 0);
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
}
// 27.3.1.1 GeneratorFunction ( p1, p2, … , pn, body ), https://tc39.es/ecma262/#sec-generatorfunction
LibJS: Convert NativeFunction::{call,construct}() to ThrowCompletionOr Both at the same time because many of them call construct() in call() and I'm not keen on adding a bunch of temporary plumbing to turn exceptions into throw completions. Also changes the return value of construct() to Object* instead of Value as it always needs to return an object; allowing an arbitrary Value is a massive foot gun.
2021-10-20 20:16:30 +00:00
ThrowCompletionOr<Value> GeneratorFunctionConstructor::call()
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
{
LibJS: Convert NativeFunction::{call,construct}() to ThrowCompletionOr Both at the same time because many of them call construct() in call() and I'm not keen on adding a bunch of temporary plumbing to turn exceptions into throw completions. Also changes the return value of construct() to Object* instead of Value as it always needs to return an object; allowing an arbitrary Value is a massive foot gun.
2021-10-20 20:16:30 +00:00
return TRY(construct(*this));
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
}
LibJS: Update CreateDynamicFunction to latest spec The use of extract_parameter_arguments_and_body() here is to make things a little less awkward. If we were to exactly follow spec there would be an awkward handling of the case that no arguments were provided and we needed to provide an empty string. To do this, we would need to either: - Provide an Optional<Value> for bodyString to CreateDynamicFunction - Create a new empty PrimitiveString wrapped in a JS Value. Either case is somewhat awkward. Instead, just refactor this logic outside of CreateDynamicFunction and make the caller do it. Otherwise, this commit prepares for the new definition of HostEnsureCanCompileStrings.
2024-11-03 07:10:56 +00:00
// 27.3.1.1 GeneratorFunction ( ...parameterArgs, bodyArg ), https://tc39.es/ecma262/#sec-generatorfunction
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
ThrowCompletionOr<GC::Ref<Object>> GeneratorFunctionConstructor::construct(FunctionObject& new_target)
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
{
LibJS: Implement create_dynamic_function() according to the spec The three major changes are: - Parsing parameters, the function body, and then the full assembled function source all separately. This is required by the spec, as function parameters and body must be valid each on their own, which cannot be guaranteed if we only ever parse the full function. - Returning an ECMAScriptFunctionObject instead of a FunctionExpression that needs to be evaluated separately. This vastly simplifies the {Async,AsyncGenerator,Generator,}Function constructor implementations. Drop '_node' from the function name accordingly. - The prototype is now determined via GetPrototypeFromConstructor and passed to OrdinaryFunctionCreate.
2022-01-15 16:26:06 +00:00
auto& vm = this->vm();
LibJS: Implement GeneratorFunctionConstructor::construct
2021-06-16 17:52:48 +00:00
LibJS: Implement create_dynamic_function() according to the spec The three major changes are: - Parsing parameters, the function body, and then the full assembled function source all separately. This is required by the spec, as function parameters and body must be valid each on their own, which cannot be guaranteed if we only ever parse the full function. - Returning an ECMAScriptFunctionObject instead of a FunctionExpression that needs to be evaluated separately. This vastly simplifies the {Async,AsyncGenerator,Generator,}Function constructor implementations. Drop '_node' from the function name accordingly. - The prototype is now determined via GetPrototypeFromConstructor and passed to OrdinaryFunctionCreate.
2022-01-15 16:26:06 +00:00
// 1. Let C be the active function object.
auto* constructor = vm.active_function_object();
LibJS: Implement GeneratorFunctionConstructor::construct
2021-06-16 17:52:48 +00:00
LibJS: Update CreateDynamicFunction to latest spec The use of extract_parameter_arguments_and_body() here is to make things a little less awkward. If we were to exactly follow spec there would be an awkward handling of the case that no arguments were provided and we needed to provide an empty string. To do this, we would need to either: - Provide an Optional<Value> for bodyString to CreateDynamicFunction - Create a new empty PrimitiveString wrapped in a JS Value. Either case is somewhat awkward. Instead, just refactor this logic outside of CreateDynamicFunction and make the caller do it. Otherwise, this commit prepares for the new definition of HostEnsureCanCompileStrings.
2024-11-03 07:10:56 +00:00
// 2. If bodyArg is not present, set bodyArg to the empty String.
// NOTE: This does that, as well as the string extraction done inside of CreateDynamicFunction
auto extracted = TRY(extract_parameter_arguments_and_body(vm, vm.running_execution_context().arguments));
LibJS: Implement GeneratorFunctionConstructor::construct
2021-06-16 17:52:48 +00:00
LibJS: Update CreateDynamicFunction to latest spec The use of extract_parameter_arguments_and_body() here is to make things a little less awkward. If we were to exactly follow spec there would be an awkward handling of the case that no arguments were provided and we needed to provide an empty string. To do this, we would need to either: - Provide an Optional<Value> for bodyString to CreateDynamicFunction - Create a new empty PrimitiveString wrapped in a JS Value. Either case is somewhat awkward. Instead, just refactor this logic outside of CreateDynamicFunction and make the caller do it. Otherwise, this commit prepares for the new definition of HostEnsureCanCompileStrings.
2024-11-03 07:10:56 +00:00
// 3. Return ? CreateDynamicFunction(C, NewTarget, generator, parameterArgs, bodyArg).
return TRY(FunctionConstructor::create_dynamic_function(vm, *constructor, &new_target, FunctionKind::Generator, extracted.parameters, extracted.body));
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 07:04:08 +00:00
}
}
Reference in a new issue Copy permalink