beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-29 11:00:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Userland/Libraries/LibJS/Runtime/PropertyName.h

241 lines
6.3 KiB
C
Raw Normal View History

LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
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 a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
*/
#pragma once
#include <AK/FlyString.h>
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
#include <LibJS/Runtime/StringOrSymbol.h>
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
namespace JS {
class PropertyName {
public:
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 16:59:07 +00:00
enum class Type : u8 {
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 18:24:45 +00:00
Invalid,
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
Number,
String,
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
Symbol,
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
};
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 16:59:07 +00:00
enum class StringMayBeNumber {
Yes,
No,
};
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
static PropertyName from_value(GlobalObject& global_object, Value value)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
LibJS: Fix PropertyName::from_value() for negative and non-int numbers It was converting *any* number to an i32 index, which obviously is not correct for negative ints, doubles, infinity and nan. Fixes #3712.
2020-10-07 18:53:30 +00:00
if (value.is_empty())
return {};
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
if (value.is_symbol())
LibJS: Change PropertyName(Symbol*) => PropertyName(Symbol&) Requires a bunch of find-and-replace updates across LibJS, but constructing a PropertyName from a nullptr Symbol* should not be possible - let's enforce this at the compiler level instead of using VERIFY() (and already dereference Symbol pointers at the call site).
2021-06-25 17:37:14 +00:00
return value.as_symbol();
LibJS: Don't treat 2^32 - 1 as numeric PropertyName 10.4.2 Array Exotic Objects https://tc39.es/ecma262/#sec-array-exotic-objects A String property name P is an array index if and only if ToString(ToUint32(P)) equals P and ToUint32(P) is not the same value as 𝔽(2^32 - 1).
2021-07-06 15:45:54 +00:00
if (value.is_integral_number() && value.as_double() >= 0 && value.as_double() < NumericLimits<u32>::max())
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 17:41:10 +00:00
return value.as_u32();
LibJS: Don't create "valid" PropertyName from null string When value.to_string() throws an exception it returns a null string in which case we must not construct a valid PropertyName. Also ASSERT in PropertyName(String) and PropertyName(FlyString) to prevent this from happening in the future. Fixes #3941.
2020-11-04 09:48:48 +00:00
auto string = value.to_string(global_object);
if (string.is_null())
return {};
return string;
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
}
PropertyName() { }
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 18:24:45 +00:00
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 17:41:10 +00:00
template<Integral T>
PropertyName(T index)
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
{
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 17:41:10 +00:00
// FIXME: Replace this with requires(IsUnsigned<T>)?
// Needs changes in various places using `int` (but not actually being in the negative range)
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(index >= 0);
LibJS: Add a way of constructing PropertyName with values above 2**32-1 This is often needed in ArrayPrototype when getting items with indices above 2**32-1 is possible since length is at most 2**53-1. This also fixes a number of these cases in ArrayPrototype where the type was not big enough to hold the potential values.
2021-07-07 12:17:51 +00:00
if constexpr (NumericLimits<T>::max() >= NumericLimits<u32>::max()) {
if (index >= NumericLimits<u32>::max()) {
m_string = String::number(index);
m_type = Type::String;
m_string_may_be_number = false;
return;
}
}
m_type = Type::Number;
m_number = index;
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
}
LibJS: Convert PropertyName and StringOrSymbol to east-const style
2021-06-13 09:49:24 +00:00
PropertyName(char const* chars)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 04:33:37 +00:00
: m_type(Type::String)
, m_string(FlyString(chars))
{
}
LibJS: Convert PropertyName and StringOrSymbol to east-const style
2021-06-13 09:49:24 +00:00
PropertyName(String const& string)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 04:33:37 +00:00
: m_type(Type::String)
, m_string(FlyString(string))
{
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
VERIFY(!m_string.is_null());
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 04:33:37 +00:00
}
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
PropertyName(FlyString string, StringMayBeNumber string_may_be_number = StringMayBeNumber::Yes)
LibJS: Optimize PropertyName and StringPrototype for size We can reduce the amount of padding the compiler adds in order to ensure data alignment of member variables by ordering the types in a struct by size in decending order. Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
2021-10-10 07:00:15 +00:00
: m_string_may_be_number(string_may_be_number == StringMayBeNumber::Yes)
, m_type(Type::String)
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_string(move(string))
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
{
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
VERIFY(!m_string.is_null());
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
}
LibJS: Change PropertyName(Symbol*) => PropertyName(Symbol&) Requires a bunch of find-and-replace updates across LibJS, but constructing a PropertyName from a nullptr Symbol* should not be possible - let's enforce this at the compiler level instead of using VERIFY() (and already dereference Symbol pointers at the call site).
2021-06-25 17:37:14 +00:00
PropertyName(Symbol& symbol)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
: m_type(Type::Symbol)
LibJS: Change PropertyName(Symbol*) => PropertyName(Symbol&) Requires a bunch of find-and-replace updates across LibJS, but constructing a PropertyName from a nullptr Symbol* should not be possible - let's enforce this at the compiler level instead of using VERIFY() (and already dereference Symbol pointers at the call site).
2021-06-25 17:37:14 +00:00
, m_symbol(&symbol)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
}
LibJS: Convert PropertyName and StringOrSymbol to east-const style
2021-06-13 09:49:24 +00:00
PropertyName(StringOrSymbol const& string_or_symbol)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
if (string_or_symbol.is_string()) {
m_string = string_or_symbol.as_string();
m_type = Type::String;
} else if (string_or_symbol.is_symbol()) {
m_symbol = const_cast<Symbol*>(string_or_symbol.as_symbol());
m_type = Type::Symbol;
}
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
ALWAYS_INLINE Type type() const { return m_type; }
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 18:24:45 +00:00
bool is_valid() const { return m_type != Type::Invalid; }
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 17:51:07 +00:00
bool is_number() const
{
if (m_type == Type::Number)
return true;
if (m_type != Type::String || !m_string_may_be_number)
return false;
return const_cast<PropertyName*>(this)->try_coerce_into_number();
}
bool is_string() const
{
if (m_type != Type::String)
return false;
if (!m_string_may_be_number)
return true;
return !const_cast<PropertyName*>(this)->try_coerce_into_number();
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
bool is_symbol() const { return m_type == Type::Symbol; }
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 17:51:07 +00:00
bool try_coerce_into_number()
{
VERIFY(m_string_may_be_number);
LibJS: Make string to integer parsing for properties more strict This does break two TypedArray test262 test but those really were not correct because hasProperty was not implemented
2021-06-22 18:13:42 +00:00
if (m_string.is_empty()) {
m_string_may_be_number = false;
return false;
}
if (char first = m_string.characters()[0]; first < '0' || first > '9') {
m_string_may_be_number = false;
return false;
} else if (m_string.length() > 1 && first == '0') {
m_string_may_be_number = false;
return false;
}
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 17:41:10 +00:00
auto property_index = m_string.to_uint(TrimWhitespace::No);
LibJS: Don't treat 2^32 - 1 as numeric PropertyName 10.4.2 Array Exotic Objects https://tc39.es/ecma262/#sec-array-exotic-objects A String property name P is an array index if and only if ToString(ToUint32(P)) equals P and ToUint32(P) is not the same value as 𝔽(2^32 - 1).
2021-07-06 15:45:54 +00:00
if (!property_index.has_value() || property_index.value() == NumericLimits<u32>::max()) {
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 17:51:07 +00:00
m_string_may_be_number = false;
return false;
}
m_type = Type::Number;
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 17:41:10 +00:00
m_number = *property_index;
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 17:51:07 +00:00
return true;
}
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
LibJS: Change PropertyName::as_number() return type to u32 This is how it's stored internally - even though we still only construct from i32. I had the compiler yell at me while trying something with this and didn't want to add yet another cast, so let's quickly fix this.
2021-04-25 20:42:48 +00:00
u32 as_number() const
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(is_number());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
return m_number;
}
LibJS: Convert PropertyName and StringOrSymbol to east-const style
2021-06-13 09:49:24 +00:00
FlyString const& as_string() const
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(is_string());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
return m_string;
}
LibJS: Convert PropertyName and StringOrSymbol to east-const style
2021-06-13 09:49:24 +00:00
Symbol const* as_symbol() const
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(is_symbol());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
return m_symbol;
}
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +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
String to_string() const
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(is_valid());
VERIFY(!is_symbol());
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
if (is_string())
return as_string();
return String::number(as_number());
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
StringOrSymbol to_string_or_symbol() const
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(is_valid());
VERIFY(!is_number());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
if (is_string())
return StringOrSymbol(as_string());
return StringOrSymbol(as_symbol());
}
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
private:
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 16:59:07 +00:00
bool m_string_may_be_number { true };
LibJS: Optimize PropertyName and StringPrototype for size We can reduce the amount of padding the compiler adds in order to ensure data alignment of member variables by ordering the types in a struct by size in decending order. Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
2021-10-10 07:00:15 +00:00
Type m_type { Type::Invalid };
u32 m_number { 0 };
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
FlyString m_string;
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
Symbol* m_symbol { nullptr };
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
};
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
struct PropertyNameTraits : public Traits<PropertyName> {
static unsigned hash(PropertyName const& name)
{
VERIFY(name.is_valid());
if (name.is_string())
return name.as_string().hash();
if (name.is_number())
return int_hash(name.as_number());
return ptr_hash(name.as_symbol());
}
static bool equals(PropertyName const& a, PropertyName const& b)
{
if (a.type() != b.type())
return false;
switch (a.type()) {
case PropertyName::Type::Number:
return a.as_number() == b.as_number();
case PropertyName::Type::String:
return a.as_string() == b.as_string();
case PropertyName::Type::Symbol:
return a.as_symbol() == b.as_symbol();
default:
VERIFY_NOT_REACHED();
}
}
};
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
}
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 16:59:07 +00:00
namespace AK {
template<>
struct Formatter<JS::PropertyName> : Formatter<StringView> {
LibJS: Handle invalid and symbol PropertyName in its AK::Formatter This would previously crash as we used to_string() without checking the type first. Circumvent that by handling invalid and numeric ones separately and then using to_string_or_symbol().
2021-07-04 16:59:07 +00:00
void format(FormatBuilder& builder, JS::PropertyName const& property_name)
{
if (!property_name.is_valid())
Formatter<StringView>::format(builder, "<invalid PropertyName>");
else if (property_name.is_number())
Formatter<StringView>::format(builder, String::number(property_name.as_number()));
else
Formatter<StringView>::format(builder, property_name.to_string_or_symbol().to_display_string());
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 16:59:07 +00:00
}
};
}
Reference in a new issue Copy permalink