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/GeneratorObject.h

51 lines
1.7 KiB
C
Raw Permalink Normal View History

LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
/*
* Copyright (c) 2021, Ali Mohammad Pur <mpfard@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Convert GeneratorObject.prototype to be a PrototypeObject The added #include in GeneratorObject.h is to resolve usage of Bytecode::RegisterWindow.
2021-09-11 20:23:42 +00:00
#include <LibJS/Bytecode/Interpreter.h>
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: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
#include <LibJS/Runtime/Object.h>
namespace JS {
LibJS: Allow GeneratorObject to be subclassed In the Iterator Helpers proposal, we must create a generator object with additional internal slots and behavior differences. GeneratorObject is currently implemented assuming it wraps around an ECMAScriptFunctionObject with generated bytecode. In this proposal, we instead have "Abstract Closure" blocks. So this marks the `execute` method as virtual, to allow the future subclass to essentially just invoke those closures. We will also require mutable access to the [[GeneratorState]] internal slot.
2023-07-16 18:37:35 +00:00
class GeneratorObject : public Object {
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
JS_OBJECT(GeneratorObject, Object);
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_DECLARE_ALLOCATOR(GeneratorObject);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
public:
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
static ThrowCompletionOr<GC::Ref<GeneratorObject>> create(Realm&, Value, ECMAScriptFunctionObject*, NonnullOwnPtr<ExecutionContext>);
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 16:25:06 +00:00
virtual ~GeneratorObject() override = default;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
void visit_edges(Cell::Visitor&) override;
LibJS: Convert GeneratorObject's [[GeneratorBrand]] to a StringView This optional parameter is not currently set by any caller, but will be for the Iterator Helpers proposal. In all specs, this parameter is a static string, so we can just use a StringView rather than allocating a (Deprecated)String on each invocation. This also changes this optional parameter to be passed by const-ref, as it does not need to be copied.
2023-07-16 18:33:20 +00:00
ThrowCompletionOr<Value> resume(VM&, Value value, Optional<StringView> const& generator_brand);
ThrowCompletionOr<Value> resume_abrupt(VM&, JS::Completion abrupt_completion, Optional<StringView> const& generator_brand);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
enum class GeneratorState {
SuspendedStart,
SuspendedYield,
Executing,
Completed,
};
LibJS: Allow GeneratorObject to be subclassed In the Iterator Helpers proposal, we must create a generator object with additional internal slots and behavior differences. GeneratorObject is currently implemented assuming it wraps around an ECMAScriptFunctionObject with generated bytecode. In this proposal, we instead have "Abstract Closure" blocks. So this marks the `execute` method as virtual, to allow the future subclass to essentially just invoke those closures. We will also require mutable access to the [[GeneratorState]] internal slot.
2023-07-16 18:37:35 +00:00
GeneratorState generator_state() const { return m_generator_state; }
void set_generator_state(GeneratorState generator_state) { m_generator_state = generator_state; }
protected:
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 15:45:45 +00:00
GeneratorObject(Realm&, Object& prototype, NonnullOwnPtr<ExecutionContext>, Optional<StringView> generator_brand = {});
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
LibJS: Convert GeneratorObject's [[GeneratorBrand]] to a StringView This optional parameter is not currently set by any caller, but will be for the Iterator Helpers proposal. In all specs, this parameter is a static string, so we can just use a StringView rather than allocating a (Deprecated)String on each invocation. This also changes this optional parameter to be passed by const-ref, as it does not need to be copied.
2023-07-16 18:33:20 +00:00
ThrowCompletionOr<GeneratorState> validate(VM&, Optional<StringView> const& generator_brand);
LibJS: Allow GeneratorObject to be subclassed In the Iterator Helpers proposal, we must create a generator object with additional internal slots and behavior differences. GeneratorObject is currently implemented assuming it wraps around an ECMAScriptFunctionObject with generated bytecode. In this proposal, we instead have "Abstract Closure" blocks. So this marks the `execute` method as virtual, to allow the future subclass to essentially just invoke those closures. We will also require mutable access to the [[GeneratorState]] internal slot.
2023-07-16 18:37:35 +00:00
virtual ThrowCompletionOr<Value> execute(VM&, JS::Completion const& completion);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
LibJS: Allow GeneratorObject to be subclassed In the Iterator Helpers proposal, we must create a generator object with additional internal slots and behavior differences. GeneratorObject is currently implemented assuming it wraps around an ECMAScriptFunctionObject with generated bytecode. In this proposal, we instead have "Abstract Closure" blocks. So this marks the `execute` method as virtual, to allow the future subclass to essentially just invoke those closures. We will also require mutable access to the [[GeneratorState]] internal slot.
2023-07-16 18:37:35 +00:00
private:
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 15:45:45 +00:00
NonnullOwnPtr<ExecutionContext> m_execution_context;
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::Ptr<ECMAScriptFunctionObject> m_generating_function;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
Value m_previous_value;
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
GeneratorState m_generator_state { GeneratorState::SuspendedStart };
LibJS: Convert GeneratorObject's [[GeneratorBrand]] to a StringView This optional parameter is not currently set by any caller, but will be for the Iterator Helpers proposal. In all specs, this parameter is a static string, so we can just use a StringView rather than allocating a (Deprecated)String on each invocation. This also changes this optional parameter to be passed by const-ref, as it does not need to be copied.
2023-07-16 18:33:20 +00:00
Optional<StringView> m_generator_brand;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
};
}
Reference in a new issue Copy permalink