Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/DeclarativeEnvironment.h

140 lines
4.9 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
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
#include <AK/DeprecatedFlyString.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 <AK/HashMap.h>
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Convert has_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 17:07:32 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
class DeclarativeEnvironment : public Environment {
JS_ENVIRONMENT(DeclarativeEnvironment, Environment);
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 09:45:05 +01:00
JS_DECLARE_ALLOCATOR(DeclarativeEnvironment);
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 fast path for creating per-iteration DeclarativeEnvironment The steps for creating a DeclarativeEnvironment for each iteration of a for-loop can be done equivalently to the spec without following the spec directly. For each binding creating in the loop's init expression, we: 1. Create a new binding in the new environment. 2. Grab the current value of the binding in the old environment. 3. Set the value in the new environment to the old value. This can be replaced by initializing the bindings vector in the new environment directly with the bindings in the old environment (but only copying the bindings of the init statement).
2022-03-09 15:37:10 -05:00
struct Binding {
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString name;
LibJS: Add a fast path for creating per-iteration DeclarativeEnvironment The steps for creating a DeclarativeEnvironment for each iteration of a for-loop can be done equivalently to the spec without following the spec directly. For each binding creating in the loop's init expression, we: 1. Create a new binding in the new environment. 2. Grab the current value of the binding in the old environment. 3. Set the value in the new environment to the old value. This can be replaced by initializing the bindings vector in the new environment directly with the bindings in the old environment (but only copying the bindings of the init statement).
2022-03-09 15:37:10 -05:00
Value value;
bool strict { false };
bool mutable_ { false };
bool can_be_deleted { false };
bool initialized { false };
};
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: Add a fast path for creating per-iteration DeclarativeEnvironment The steps for creating a DeclarativeEnvironment for each iteration of a for-loop can be done equivalently to the spec without following the spec directly. For each binding creating in the loop's init expression, we: 1. Create a new binding in the new environment. 2. Grab the current value of the binding in the old environment. 3. Set the value in the new environment to the old value. This can be replaced by initializing the bindings vector in the new environment directly with the bindings in the old environment (but only copying the bindings of the init statement).
2022-03-09 15:37:10 -05:00
static DeclarativeEnvironment* create_for_per_iteration_bindings(Badge<ForStatement>, DeclarativeEnvironment& other, size_t bindings_size);
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 10:25:06 -06:00
virtual ~DeclarativeEnvironment() override = default;
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: Mark classes and virtual functions `final` where possible These cases were found with GCC's `-Wsuggest-final-{types,methods}` warnings, which catch calls that could have been devirtualized had we declared the functions `final` in the source. To reproduce, Link Time Optimization needs to be enabled. The easiest way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION` cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli decompressor might needs to be changed to an absolute path for this to work. This commit also removes a pair of unused virtual functions.
2023-08-13 12:53:46 +02:00
virtual ThrowCompletionOr<bool> has_binding(DeprecatedFlyString const& name, Optional<size_t>* = nullptr) const override final;
virtual ThrowCompletionOr<void> create_mutable_binding(VM&, DeprecatedFlyString const& name, bool can_be_deleted) override final;
virtual ThrowCompletionOr<void> create_immutable_binding(VM&, DeprecatedFlyString const& name, bool strict) override final;
virtual ThrowCompletionOr<void> initialize_binding(VM&, DeprecatedFlyString const& name, Value, InitializeBindingHint) override final;
virtual ThrowCompletionOr<void> set_mutable_binding(VM&, DeprecatedFlyString const& name, Value, bool strict) override final;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
virtual ThrowCompletionOr<Value> get_binding_value(VM&, DeprecatedFlyString const& name, bool strict) override;
virtual ThrowCompletionOr<bool> delete_binding(VM&, DeprecatedFlyString const& name) override;
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
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void initialize_or_set_mutable_binding(Badge<ScopeNode>, VM&, DeprecatedFlyString const& name, Value value);
ThrowCompletionOr<void> initialize_or_set_mutable_binding(VM&, DeprecatedFlyString const& name, Value value);
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
js: Allow for completion of lexically declared variables This does require us to have a method which lists all the bindings in a declarative environment which is not in the spec.
2021-10-03 13:20:15 +02:00
// This is not a method defined in the spec! Do not use this in any LibJS (or other spec related) code.
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
[[nodiscard]] Vector<DeprecatedFlyString> bindings() const
LibJS: Combine DeclarativeEnvironment's bindings and names into one list This reduces the size of the DeclarativeEnvironment from 72 bytes to 48 bytes. This savings helps in the context of nested for-loops which use 'let' to bind the initial variable declarations. In this case, the spec dicates we create a new environment for each loop iteration by way of the CreatePerIterationEnvironment AO. In particular, test262's generated RegExp tests contains many loops of the form: for (let i = 0; i < a_number_on_the_order_of_10; ++i) for (let j = 0; j < a_number_on_the_order_of_10_thousand; ++j) This results in creating hundreds of thousands of environments.
2022-03-08 11:56:42 -05:00
{
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
Vector<DeprecatedFlyString> names;
LibJS: Combine DeclarativeEnvironment's bindings and names into one list This reduces the size of the DeclarativeEnvironment from 72 bytes to 48 bytes. This savings helps in the context of nested for-loops which use 'let' to bind the initial variable declarations. In this case, the spec dicates we create a new environment for each loop iteration by way of the CreatePerIterationEnvironment AO. In particular, test262's generated RegExp tests contains many loops of the form: for (let i = 0; i < a_number_on_the_order_of_10; ++i) for (let j = 0; j < a_number_on_the_order_of_10_thousand; ++j) This results in creating hundreds of thousands of environments.
2022-03-08 11:56:42 -05:00
names.ensure_capacity(m_bindings.size());
for (auto const& binding : m_bindings)
names.unchecked_append(binding.name);
return names;
}
js: Allow for completion of lexically declared variables This does require us to have a method which lists all the bindings in a declarative environment which is not in the spec.
2021-10-03 13:20:15 +02:00
LibJS: Replace GlobalObject with VM in Environment AOs [Part 5/19]
2022-08-21 15:12:43 +01:00
ThrowCompletionOr<void> set_mutable_binding_direct(VM&, size_t index, Value, bool strict);
LibJS: Make DeclarativeEnvironment based on bindings instead of indices This will allow other environments which extend DeclarativeEnvironment to provide their own custom bindings.
2022-09-01 23:22:17 +02:00
ThrowCompletionOr<Value> get_binding_value_direct(VM&, size_t index, bool strict);
LibJS: Shrink DeclarativeEnvironment bindings vector to fit After setting up all the bindings in function_declaration_instantiation, we now ask DeclarativeEnvironment to do a shrink_to_fit() on its vector of bindings. This ends up saving 5.6 MiB on twitter.com/awesomekling :^)
2022-11-26 20:33:52 +01:00
void shrink_to_fit();
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
void ensure_capacity(size_t needed_capacity)
{
m_bindings.ensure_capacity(needed_capacity);
}
LibJS: Add modification counter in DeclarativeEnvironment This counter is incremented whenever a mutating operation occurs within the environment's set of bindings. It is going to be used by GetGlobal instruction to correctly invalidate cache when global declarative environment is mutated.
2023-07-12 14:30:51 +02:00
[[nodiscard]] u64 environment_serial_number() const { return m_environment_serial_number; }
LibJS: Make DeclarativeEnvironment based on bindings instead of indices This will allow other environments which extend DeclarativeEnvironment to provide their own custom bindings.
2022-09-01 23:22:17 +02:00
private:
ThrowCompletionOr<Value> get_binding_value_direct(VM&, Binding&, bool strict);
ThrowCompletionOr<void> set_mutable_binding_direct(VM&, Binding&, Value, bool strict);
LibJS: Add direct (indexed) binding accessors to DeclarativeEnvironment This patch adds two DeclarativeEnvironment APIs: - get_binding_value_direct() - set_mutable_binding_direct() These work identically to their non-direct-suffixed counterparts, but take an index instead of a bound name. This will allow someone who has a binding index to get/set that binding directly without any additional hash lookups.
2021-10-07 00:10:00 +02:00
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
friend Completion dispose_resources(VM&, GCPtr<DeclarativeEnvironment>, Completion);
Vector<DisposableResource> const& disposable_resource_stack() const { return m_disposable_resource_stack; }
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:
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
DeclarativeEnvironment();
explicit DeclarativeEnvironment(Environment* parent_environment);
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
DeclarativeEnvironment(Environment* parent_environment, ReadonlySpan<Binding> bindings);
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
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
virtual void visit_edges(Visitor&) override;
LibJS: Make DeclarativeEnvironment based on bindings instead of indices This will allow other environments which extend DeclarativeEnvironment to provide their own custom bindings.
2022-09-01 23:22:17 +02:00
class BindingAndIndex {
public:
Binding& binding()
{
if (m_referenced_binding)
return *m_referenced_binding;
return m_temporary_binding;
}
BindingAndIndex(Binding* binding, Optional<size_t> index)
: m_referenced_binding(binding)
, m_index(move(index))
{
}
explicit BindingAndIndex(Binding temporary_binding)
: m_temporary_binding(move(temporary_binding))
{
}
Optional<size_t> const& index() const { return m_index; }
private:
Binding* m_referenced_binding { nullptr };
Binding m_temporary_binding {};
Optional<size_t> m_index;
};
friend class ModuleEnvironment;
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
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
virtual Optional<BindingAndIndex> find_binding_and_index(DeprecatedFlyString const& name) const
LibJS: Combine DeclarativeEnvironment's bindings and names into one list This reduces the size of the DeclarativeEnvironment from 72 bytes to 48 bytes. This savings helps in the context of nested for-loops which use 'let' to bind the initial variable declarations. In this case, the spec dicates we create a new environment for each loop iteration by way of the CreatePerIterationEnvironment AO. In particular, test262's generated RegExp tests contains many loops of the form: for (let i = 0; i < a_number_on_the_order_of_10; ++i) for (let j = 0; j < a_number_on_the_order_of_10_thousand; ++j) This results in creating hundreds of thousands of environments.
2022-03-08 11:56:42 -05:00
{
auto it = m_bindings.find_if([&](auto const& binding) {
return binding.name == name;
});
if (it == m_bindings.end())
return {};
LibJS: Make DeclarativeEnvironment based on bindings instead of indices This will allow other environments which extend DeclarativeEnvironment to provide their own custom bindings.
2022-09-01 23:22:17 +02:00
return BindingAndIndex { const_cast<Binding*>(&(*it)), it.index() };
LibJS: Combine DeclarativeEnvironment's bindings and names into one list This reduces the size of the DeclarativeEnvironment from 72 bytes to 48 bytes. This savings helps in the context of nested for-loops which use 'let' to bind the initial variable declarations. In this case, the spec dicates we create a new environment for each loop iteration by way of the CreatePerIterationEnvironment AO. In particular, test262's generated RegExp tests contains many loops of the form: for (let i = 0; i < a_number_on_the_order_of_10; ++i) for (let j = 0; j < a_number_on_the_order_of_10_thousand; ++j) This results in creating hundreds of thousands of environments.
2022-03-08 11:56:42 -05:00
}
LibJS: Make DeclarativeEnvironment based on bindings instead of indices This will allow other environments which extend DeclarativeEnvironment to provide their own custom bindings.
2022-09-01 23:22:17 +02:00
private:
virtual bool is_declarative_environment() const override { return true; }
LibJS: Make DeclarativeEnvironment store bindings in a Vector The previous storage for DeclarativeEnvironment looked like this: HashMap<FlyString, Binding> m_bindings; This patch changes that to: HashMap<FlyString, size_t> m_names; Vector<Binding> m_bindings; The main goal here is to give each binding an index that can ultimately be cached and used for optimized environment accesses.
2021-10-06 23:38:46 +02:00
Vector<Binding> m_bindings;
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
Vector<DisposableResource> m_disposable_resource_stack;
LibJS: Add modification counter in DeclarativeEnvironment This counter is incremented whenever a mutating operation occurs within the environment's set of bindings. It is going to be used by GetGlobal instruction to correctly invalidate cache when global declarative environment is mutated.
2023-07-12 14:30:51 +02:00
u64 m_environment_serial_number { 0 };
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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
inline bool Environment::fast_is<DeclarativeEnvironment>() const { return is_declarative_environment(); }
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