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

141 lines
4 KiB
C
Raw Permalink Normal View History

LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2020-2021, Andreas Kling <andreas@ladybird.org>
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00: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 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
*/
#pragma once
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 10:24:46 +00:00
#include <LibJS/Runtime/Environment.h>
LibJS: Fast non-local variable access :^) This patch introduces the "environment coordinate" concept, which encodes the distance from a variable access to the binding it ends up resolving to. EnvironmentCoordinate has two fields: - hops: The number of hops up the lexical environment chain we have to make before getting to the resolved binding. - index: The index of the resolved binding within its declarative environment record. Whenever a variable lookup resolves somewhere inside a declarative environment, we now cache the coordinates and reuse them in subsequent lookups. This is achieved via a coordinate cache in JS::Identifier. Note that non-strict direct eval() breaks this optimization and so it will not be performed if the resolved environment has been permanently screwed by eval(). This makes variable access *significantly* faster. :^)
2021-10-06 23:06:21 +00:00
#include <LibJS/Runtime/EnvironmentCoordinate.h>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
#include <LibJS/Runtime/PropertyKey.h>
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
#include <LibJS/Runtime/Value.h>
namespace JS {
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-09 00:23:00 +00:00
Reference make_private_reference(VM&, Value base_value, DeprecatedFlyString const& private_identifier);
LibJS: Add private references
2021-10-12 19:48:50 +00:00
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
class Reference {
public:
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
enum class BaseType : u8 {
Unresolvable,
Value,
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 10:24:46 +00:00
Environment,
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
};
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
Reference(BaseType type, PropertyKey name, bool strict)
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
: m_base_type(type)
LibJS: Use move semantics more when creating Reference objects Turns a bunch of FlyString copies into moves.
2021-09-11 17:03:38 +00:00
, m_name(move(name))
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
, m_strict(strict)
{
}
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
Reference(Value base, PropertyKey name, Value this_value, bool strict = false)
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
: m_base_type(BaseType::Value)
, m_base_value(base)
LibJS: Use move semantics more when creating Reference objects Turns a bunch of FlyString copies into moves.
2021-09-11 17:03:38 +00:00
, m_name(move(name))
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
, m_this_value(this_value)
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 10:37:27 +00:00
, m_strict(strict)
{
}
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-09 00:23:00 +00:00
Reference(Environment& base, DeprecatedFlyString referenced_name, bool strict = false, Optional<EnvironmentCoordinate> environment_coordinate = {})
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 10:24:46 +00:00
: m_base_type(BaseType::Environment)
, m_base_environment(&base)
LibJS: Use move semantics more when creating Reference objects Turns a bunch of FlyString copies into moves.
2021-09-11 17:03:38 +00:00
, m_name(move(referenced_name))
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 12:44:48 +00:00
, m_strict(strict)
LibJS: Fast non-local variable access :^) This patch introduces the "environment coordinate" concept, which encodes the distance from a variable access to the binding it ends up resolving to. EnvironmentCoordinate has two fields: - hops: The number of hops up the lexical environment chain we have to make before getting to the resolved binding. - index: The index of the resolved binding within its declarative environment record. Whenever a variable lookup resolves somewhere inside a declarative environment, we now cache the coordinates and reuse them in subsequent lookups. This is achieved via a coordinate cache in JS::Identifier. Note that non-strict direct eval() breaks this optimization and so it will not be performed if the resolved environment has been permanently screwed by eval(). This makes variable access *significantly* faster. :^)
2021-10-06 23:06:21 +00:00
, m_environment_coordinate(move(environment_coordinate))
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 12:44:48 +00:00
{
}
LibJS: Add private references
2021-10-12 19:48:50 +00:00
Reference(Value base, PrivateName name)
: m_base_type(BaseType::Value)
, m_base_value(base)
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 20:36:48 +00:00
, m_name(move(name))
LibJS: Add private references
2021-10-12 19:48:50 +00:00
, m_strict(true)
{
}
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
Value base() const
{
VERIFY(m_base_type == BaseType::Value);
return m_base_value;
}
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
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 10:24:46 +00:00
Environment& base_environment() const
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
{
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 10:24:46 +00:00
VERIFY(m_base_type == BaseType::Environment);
return *m_base_environment;
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
}
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 20:36:48 +00:00
PropertyKey const& name() const { return m_name.get<PropertyKey>(); }
PrivateName const& private_name() const { return m_name.get<PrivateName>(); }
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
bool is_strict() const { return m_strict; }
// 6.2.4.2 IsUnresolvableReference ( V ), https://tc39.es/ecma262/#sec-isunresolvablereference
bool is_unresolvable() const { return m_base_type == BaseType::Unresolvable; }
// 6.2.4.1 IsPropertyReference ( V ), https://tc39.es/ecma262/#sec-ispropertyreference
bool is_property_reference() const
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
{
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
if (is_unresolvable())
return false;
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 10:24:46 +00:00
if (m_base_type == BaseType::Environment)
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
return false;
LibJS: Add private references
2021-10-12 19:48:50 +00:00
return true;
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
}
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
// 6.2.4.7 GetThisValue ( V ), https://tc39.es/ecma262/#sec-getthisvalue
Value get_this_value() const
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 10:37:27 +00:00
{
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
VERIFY(is_property_reference());
if (is_super_reference())
return m_this_value;
return m_base_value;
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 10:37:27 +00:00
}
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
// 6.2.4.3 IsSuperReference ( V ), https://tc39.es/ecma262/#sec-issuperreference
bool is_super_reference() const
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 12:44:48 +00:00
{
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
return !m_this_value.is_empty();
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 12:44:48 +00:00
}
LibJS: Add private references
2021-10-12 19:48:50 +00:00
// 6.2.4.4 IsPrivateReference ( V ), https://tc39.es/ecma262/#sec-isprivatereference
bool is_private_reference() const
{
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 20:36:48 +00:00
return m_name.has<PrivateName>();
LibJS: Add private references
2021-10-12 19:48:50 +00:00
}
LibJS: Implement parsing and execution of optional chains
2021-09-14 02:26:31 +00:00
// Note: Non-standard helper.
bool is_environment_reference() const
{
return m_base_type == BaseType::Environment;
}
LibJS: Add an initialize binding hint to all initialize_binding methods This will allow us to specify things like SyncDispose and perhaps AsyncDispose in the future.
2022-12-14 12:26:10 +00:00
ThrowCompletionOr<void> initialize_referenced_binding(VM&, Value value, Environment::InitializeBindingHint hint = Environment::InitializeBindingHint::Normal) const;
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 10:44:56 +00:00
LibJS: Replace GlobalObject with VM in Reference AOs [Part 6/19]
2022-08-21 14:39:13 +00:00
ThrowCompletionOr<void> put_value(VM&, Value);
ThrowCompletionOr<Value> get_value(VM&) const;
ThrowCompletionOr<bool> delete_(VM&);
LibJS: Make AssignmentExpression assign through a Reference Reference now has assign(Interpreter&, Value) which is used to write transparently through a Reference into whatever location it refers to.
2020-04-27 10:56:09 +00:00
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 20:36:48 +00:00
bool is_valid_reference() const { return true; }
LibJS: Make the default constructed reference invalid Since we have the to_reference method on every expression class we must somehow communicate it did not actually return a reference. This (ab)uses the fact that property name is only invalid with the default constructor and already has is_valid().
2021-09-27 20:28:56 +00:00
LibJS: Fast non-local variable access :^) This patch introduces the "environment coordinate" concept, which encodes the distance from a variable access to the binding it ends up resolving to. EnvironmentCoordinate has two fields: - hops: The number of hops up the lexical environment chain we have to make before getting to the resolved binding. - index: The index of the resolved binding within its declarative environment record. Whenever a variable lookup resolves somewhere inside a declarative environment, we now cache the coordinates and reuse them in subsequent lookups. This is achieved via a coordinate cache in JS::Identifier. Note that non-strict direct eval() breaks this optimization and so it will not be performed if the resolved environment has been permanently screwed by eval(). This makes variable access *significantly* faster. :^)
2021-10-06 23:06:21 +00:00
Optional<EnvironmentCoordinate> environment_coordinate() const { return m_environment_coordinate; }
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
private:
LibJS: Replace GlobalObject with VM in Reference AOs [Part 6/19]
2022-08-21 14:39:13 +00:00
Completion throw_reference_error(VM&) const;
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 12:44:48 +00:00
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
BaseType m_base_type { BaseType::Unresolvable };
union {
LibJS: Make sure to always initialize Reference::m_base_value
2021-06-25 15:25:55 +00:00
Value m_base_value {};
LibJS: Make accessing the current function's arguments cheaper Instead of going through an environment record, make arguments of the currently executing function generate references via the argument index, which can later be resolved directly through the ExecutionContext.
2021-10-07 16:43:22 +00:00
mutable Environment* m_base_environment;
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
};
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 20:36:48 +00:00
Variant<PropertyKey, PrivateName> m_name;
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 14:27:59 +00:00
Value m_this_value;
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
bool m_strict { false };
LibJS: Add private references
2021-10-12 19:48:50 +00:00
LibJS: Fast non-local variable access :^) This patch introduces the "environment coordinate" concept, which encodes the distance from a variable access to the binding it ends up resolving to. EnvironmentCoordinate has two fields: - hops: The number of hops up the lexical environment chain we have to make before getting to the resolved binding. - index: The index of the resolved binding within its declarative environment record. Whenever a variable lookup resolves somewhere inside a declarative environment, we now cache the coordinates and reuse them in subsequent lookups. This is achieved via a coordinate cache in JS::Identifier. Note that non-strict direct eval() breaks this optimization and so it will not be performed if the resolved environment has been permanently screwed by eval(). This makes variable access *significantly* faster. :^)
2021-10-06 23:06:21 +00:00
Optional<EnvironmentCoordinate> m_environment_coordinate;
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 10:10:16 +00:00
};
}
Reference in a new issue Copy permalink