Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/DeclarativeEnvironmentRecord.h

62 lines
2.2 KiB
C
Raw Normal View History

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 21:58:22 +02:00
/*
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
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 21:58:22 +02:00
*
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 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
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 21:58:22 +02:00
*/
#pragma once
#include <AK/FlyString.h>
#include <AK/HashMap.h>
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
#include <LibJS/Runtime/EnvironmentRecord.h>
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 21:58:22 +02:00
#include <LibJS/Runtime/Value.h>
namespace JS {
LibJS: Start implementing spec-compliant variable bindings This patch adds the concept of variable bindings to the various environment record classes. The bindings are not yet hooked up to anything, this is just fleshing out all the operations. Most of this is following the spec exactly, but in a few cases we are missing the requisite abstract operations to do the exact right thing. I've added FIXME's in those cases where I noticed it.
2021-06-23 12:26:37 +02:00
struct Binding {
Value value;
bool strict;
bool mutable_ { false };
bool can_be_deleted { false };
bool initialized { false };
};
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
class DeclarativeEnvironmentRecord : public EnvironmentRecord {
LibJS: Make EnvironmentRecord inherit directly from Cell Previously, EnvironmentRecord was a JS::Object. This was done because GlobalObject inherited from EnvironmentRecord. Now that this is no longer the case, we can simplify things by making EnvironmentRecord inherit from Cell directly. This also removes the need for environment records to have a shape, which was awkward. This will be removed in the following patch.
2021-06-23 13:04:52 +02:00
JS_ENVIRONMENT_RECORD(DeclarativeEnvironmentRecord, EnvironmentRecord);
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 21:58:22 +02:00
public:
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
DeclarativeEnvironmentRecord();
LibJS: Implement the NewDeclarativeEnvironment() abstract operation
2021-06-22 00:56:14 +02:00
explicit DeclarativeEnvironmentRecord(EnvironmentRecord* parent_scope);
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
DeclarativeEnvironmentRecord(HashMap<FlyString, Variable> variables, EnvironmentRecord* parent_scope);
virtual ~DeclarativeEnvironmentRecord() override;
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 21:58:22 +02:00
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
// ^EnvironmentRecord
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
virtual Optional<Variable> get_from_environment_record(FlyString const&) const override;
virtual void put_into_environment_record(FlyString const&, Variable) override;
virtual bool delete_from_environment_record(FlyString const&) override;
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 21:58:22 +02:00
LibJS: Convert EnvironmentRecord & friends to east-const style
2021-06-21 23:26:50 +02:00
HashMap<FlyString, Variable> const& variables() const { return m_variables; }
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 21:58:22 +02:00
LibJS: Start implementing spec-compliant variable bindings This patch adds the concept of variable bindings to the various environment record classes. The bindings are not yet hooked up to anything, this is just fleshing out all the operations. Most of this is following the spec exactly, but in a few cases we are missing the requisite abstract operations to do the exact right thing. I've added FIXME's in those cases where I noticed it.
2021-06-23 12:26:37 +02:00
virtual bool has_binding(FlyString const& name) const override;
virtual void create_mutable_binding(GlobalObject&, FlyString const& name, bool can_be_deleted) override;
virtual void create_immutable_binding(GlobalObject&, FlyString const& name, bool strict) override;
virtual void initialize_binding(GlobalObject&, FlyString const& name, Value) override;
virtual void set_mutable_binding(GlobalObject&, FlyString const& name, Value, bool strict) override;
virtual Value get_binding_value(GlobalObject&, FlyString const& name, bool strict) override;
virtual bool delete_binding(GlobalObject&, FlyString const& name) override;
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
protected:
virtual void visit_edges(Visitor&) override;
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 21:58:22 +02:00
private:
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
virtual bool is_declarative_environment_record() const override { return true; }
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 21:58:22 +02:00
HashMap<FlyString, Variable> m_variables;
LibJS: Start implementing spec-compliant variable bindings This patch adds the concept of variable bindings to the various environment record classes. The bindings are not yet hooked up to anything, this is just fleshing out all the operations. Most of this is following the spec exactly, but in a few cases we are missing the requisite abstract operations to do the exact right thing. I've added FIXME's in those cases where I noticed it.
2021-06-23 12:26:37 +02:00
HashMap<FlyString, Binding> m_bindings;
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 21:58:22 +02:00
};
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
template<>
LibJS: Make EnvironmentRecord inherit directly from Cell Previously, EnvironmentRecord was a JS::Object. This was done because GlobalObject inherited from EnvironmentRecord. Now that this is no longer the case, we can simplify things by making EnvironmentRecord inherit from Cell directly. This also removes the need for environment records to have a shape, which was awkward. This will be removed in the following patch.
2021-06-23 13:04:52 +02:00
inline bool EnvironmentRecord::fast_is<DeclarativeEnvironmentRecord>() const { return is_declarative_environment_record(); }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
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 21:58:22 +02:00
}
Reference in a new issue Copy permalink