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

56 lines
2.6 KiB
C
Raw Normal View History

LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#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 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
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 GlobalEnvironment final : public Environment {
JS_ENVIRONMENT(GlobalEnvironment, Environment);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
public:
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
GlobalEnvironment(GlobalObject&, Object& this_value);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
virtual bool has_this_binding() const final { return true; }
LibJS: Convert get_this_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 16:52:34 +01:00
virtual ThrowCompletionOr<Value> get_this_binding(GlobalObject&) const final;
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
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
virtual ThrowCompletionOr<bool> has_binding(FlyString const& name, Optional<size_t>* = nullptr) const override;
LibJS: Convert create_mutable_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 18:53:25 +01:00
virtual ThrowCompletionOr<void> create_mutable_binding(GlobalObject&, FlyString const& name, bool can_be_deleted) override;
LibJS: Convert create_immutable_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 19:00:06 +01:00
virtual ThrowCompletionOr<void> create_immutable_binding(GlobalObject&, FlyString const& name, bool strict) override;
LibJS: Convert initialize_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 19:16:24 +01:00
virtual ThrowCompletionOr<void> initialize_binding(GlobalObject&, FlyString const& name, Value) override;
LibJS: Convert set_mutable_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 19:34:54 +01:00
virtual ThrowCompletionOr<void> set_mutable_binding(GlobalObject&, FlyString const& name, Value, bool strict) override;
LibJS: Convert get_binding_value() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 19:43:19 +01:00
virtual ThrowCompletionOr<Value> get_binding_value(GlobalObject&, FlyString const& name, bool strict) override;
LibJS: Convert delete_binding() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-09 19:49:08 +01:00
virtual ThrowCompletionOr<bool> delete_binding(GlobalObject&, FlyString 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
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
ObjectEnvironment& object_record() { return *m_object_record; }
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
Object& global_this_value() { return *m_global_this_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 12:24:46 +02:00
DeclarativeEnvironment& declarative_record() { return *m_declarative_record; }
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +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
bool has_var_declaration(FlyString const& name) const;
bool has_lexical_declaration(FlyString const& name) const;
LibJS: Convert has_restricted_global_property() to ThrowCompletionOr
2021-12-29 15:50:50 +01:00
ThrowCompletionOr<bool> has_restricted_global_property(FlyString const& name) const;
LibJS: Convert can_declare_global_var() to ThrowCompletionOr
2021-12-29 15:54:44 +01:00
ThrowCompletionOr<bool> can_declare_global_var(FlyString const& name) const;
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
bool can_declare_global_function(FlyString const& name) const;
void create_global_var_binding(FlyString const& name, bool can_be_deleted);
void create_global_function_binding(FlyString const& name, Value, bool can_be_deleted);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
private:
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
virtual bool is_global_environment() const override { return true; }
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
virtual void visit_edges(Visitor&) override;
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
ObjectEnvironment* m_object_record { nullptr }; // [[ObjectRecord]]
Object* m_global_this_value { nullptr }; // [[GlobalThisValue]]
DeclarativeEnvironment* m_declarative_record { nullptr }; // [[DeclarativeRecord]]
Vector<FlyString> m_var_names; // [[VarNames]]
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +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<GlobalEnvironment>() const { return is_global_environment(); }
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
}
Reference in a new issue Copy permalink