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

238 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
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
#include <AK/DeprecatedFlyString.h>
LibJS: Store symbols in a Handle inside PropertyKey If the stored symbol is custom (non-global), it is allocated on the heap, and may not be visited by anyone else, so we must register it in order to keep it alive.
2022-10-01 14:17:57 +00:00
#include <LibJS/Heap/Handle.h>
LibJS: Convert to_string() to ThrowCompletionOr Also update get_function_name() to use ThrowCompletionOr, but this is not a standard AO and should be refactored out of existence eventually.
2021-10-12 16:49:01 +00:00
#include <LibJS/Runtime/Completion.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 {
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
class PropertyKey {
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
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: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 13:00:56 +00:00
static ThrowCompletionOr<PropertyKey> from_value(VM& vm, 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())
LibJS: Convert PropertyKey::from_value() to ThrowCompletionOr Lots of MUST() - perhaps we'll eventually come up with a better API for the common case where it can't fail.
2022-01-04 21:33:30 +00:00
return PropertyKey {};
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: Convert PropertyKey::from_value() to ThrowCompletionOr Lots of MUST() - perhaps we'll eventually come up with a better API for the common case where it can't fail.
2022-01-04 21:33:30 +00:00
return PropertyKey { 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: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 00:26:52 +00:00
return static_cast<u32>(value.as_double());
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
return TRY(value.to_byte_string(vm));
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
}
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 16:25:06 +00:00
PropertyKey() = default;
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>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
PropertyKey(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()) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
m_string = ByteString::number(index);
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
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: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
PropertyKey(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)
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
, m_string(DeprecatedFlyString(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
{
}
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
PropertyKey(ByteString 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)
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
, m_string(DeprecatedFlyString(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
{
}
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
PropertyKey(DeprecatedFlyString 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: Make well-known symbol getters return NonnullGCPtr None of these are ever null after the VM has been initialized, as proved by virtually every caller immediately dereferencing the raw pointer.
2023-04-12 23:14:45 +00:00
PropertyKey(NonnullGCPtr<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: Make well-known symbol getters return NonnullGCPtr None of these are ever null after the VM has been initialized, as proved by virtually every caller immediately dereferencing the raw pointer.
2023-04-12 23:14:45 +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: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
PropertyKey(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;
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
return const_cast<PropertyKey*>(this)->try_coerce_into_number();
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_string() const
{
if (m_type != Type::String)
return false;
if (!m_string_may_be_number)
return true;
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
return !const_cast<PropertyKey*>(this)->try_coerce_into_number();
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
}
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;
}
Everywhere: Use to_number<T> instead of to_{int,uint,float,double} In a bunch of cases, this actually ends up simplifying the code as to_number will handle something such as: ``` Optional<I> opt; if constexpr (IsSigned<I>) opt = view.to_int<I>(); else opt = view.to_uint<I>(); ``` For us. The main goal here however is to have a single generic number conversion API between all of the String classes.
2023-12-23 02:59:14 +00:00
auto property_index = m_string.to_number<unsigned>(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;
}
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
DeprecatedFlyString 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
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
ByteString to_string() 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
{
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();
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
return ByteString::number(as_number());
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: 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 };
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
DeprecatedFlyString m_string;
LibJS: Store symbols in a Handle inside PropertyKey If the stored symbol is custom (non-global), it is allocated on the heap, and may not be visited by anyone else, so we must register it in order to keep it alive.
2022-10-01 14:17:57 +00:00
Handle<Symbol> 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: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
}
namespace AK {
template<>
AK: Rename GenericTraits to DefaultTraits This feels like a more fitting name for something that provides the default values for Traits.
2023-11-08 19:29:12 +00:00
struct Traits<JS::PropertyKey> : public DefaultTraits<JS::PropertyKey> {
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
static unsigned hash(JS::PropertyKey const& name)
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
{
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());
}
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
static bool equals(JS::PropertyKey const& a, JS::PropertyKey const& b)
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
{
if (a.type() != b.type())
return false;
switch (a.type()) {
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
case JS::PropertyKey::Type::Number:
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
return a.as_number() == b.as_number();
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
case JS::PropertyKey::Type::String:
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
return a.as_string() == b.as_string();
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 14:19:28 +00:00
case JS::PropertyKey::Type::Symbol:
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
return a.as_symbol() == b.as_symbol();
default:
VERIFY_NOT_REACHED();
}
}
};
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
template<>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
struct Formatter<JS::PropertyKey> : Formatter<StringView> {
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
ErrorOr<void> format(FormatBuilder& builder, JS::PropertyKey const& property_key)
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
{
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
if (!property_key.is_valid())
Meta+Userland: Simplify some formatters These are mostly minor mistakes I've encountered while working on the removal of StringView(char const*). The usage of builder.put_string over Format<FormatString>::format is preferrable as it will avoid the indirection altogether when there's no formatting to be done. Similarly, there is no need to do format(builder, "{}", number) when builder.put_u64(number) works equally well. Additionally a few Strings where only constant strings were used are replaced with StringViews.
2022-07-11 20:23:24 +00:00
return builder.put_string("<invalid PropertyKey>"sv);
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
if (property_key.is_number())
Meta+Userland: Simplify some formatters These are mostly minor mistakes I've encountered while working on the removal of StringView(char const*). The usage of builder.put_string over Format<FormatString>::format is preferrable as it will avoid the indirection altogether when there's no formatting to be done. Similarly, there is no need to do format(builder, "{}", number) when builder.put_u64(number) works equally well. Additionally a few Strings where only constant strings were used are replaced with StringViews.
2022-07-11 20:23:24 +00:00
return builder.put_u64(property_key.as_number());
return builder.put_string(property_key.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