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

119 lines
6.3 KiB
C++
Raw Normal View History

LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
/*
Everywhere: Use linusg@serenityos.org for my copyright headers
2021-04-22 22:51:19 +02:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
*/
LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors Resolves various FIXMEs :^)
2021-06-20 01:09:39 +01:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
#include <LibJS/Runtime/Error.h>
#include <LibJS/Runtime/ErrorConstructor.h>
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
namespace JS {
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
ErrorConstructor::ErrorConstructor(GlobalObject& global_object)
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
: NativeFunction(vm().names.Error, *global_object.function_prototype())
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
{
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
}
LibJS: Simplify Cell::initialize() Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-22 17:50:18 +02:00
void ErrorConstructor::initialize(GlobalObject& global_object)
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
{
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto& vm = this->vm();
LibJS: Simplify Cell::initialize() Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-22 17:50:18 +02:00
NativeFunction::initialize(global_object);
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
// 20.5.2.1 Error.prototype, https://tc39.es/ecma262/#sec-error.prototype
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
define_property(vm.names.prototype, global_object.error_prototype(), 0);
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
define_property(vm.names.length, Value(1), Attribute::Configurable);
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
}
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
// 20.5.1.1 Error ( message ), https://tc39.es/ecma262/#sec-error-message
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
Value ErrorConstructor::call()
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
{
LibJS: Remove Interpreter& argument to Function::construct() This is no longer needed, we can get everything we need from the VM.
2020-09-27 18:45:21 +02:00
return construct(*this);
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
}
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
// 20.5.1.1 Error ( message ), https://tc39.es/ecma262/#sec-error-message
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Value ErrorConstructor::construct(FunctionObject& new_target)
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
{
LibJS: Remove Interpreter& argument to Function::construct() This is no longer needed, we can get everything we need from the VM.
2020-09-27 18:45:21 +02:00
auto& vm = this->vm();
LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors Resolves various FIXMEs :^)
2021-06-20 01:09:39 +01:00
auto& global_object = this->global_object();
auto* error = ordinary_create_from_constructor<Error>(global_object, new_target, &GlobalObject::error_prototype);
if (vm.exception())
return {};
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
u8 attr = Attribute::Writable | Attribute::Configurable;
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
if (!vm.argument(0).is_undefined()) {
LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors Resolves various FIXMEs :^)
2021-06-20 01:09:39 +01:00
auto message = vm.argument(0).to_string(global_object);
LibJS: Remove Interpreter& argument to Function::construct() This is no longer needed, we can get everything we need from the VM.
2020-09-27 18:45:21 +02:00
if (vm.exception())
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
return {};
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
error->define_property(vm.names.message, js_string(vm, message), attr);
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
}
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
error->install_error_cause(vm.argument(1));
if (vm.exception())
return {};
return error;
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
}
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
ConstructorName::ConstructorName(GlobalObject& global_object) \
LibJS: Set NativeError constructors' prototype to Error constructor The FunctionPrototype is correct for ErrorConstructor itself: 20.5.2 Properties of the Error Constructor The Error constructor: - has a [[Prototype]] internal slot whose value is %Function.prototype%. However, not for all the other "NativeError" constructors: 20.5.6.2 Properties of the NativeError Constructors Each NativeError constructor: - has a [[Prototype]] internal slot whose value is %Error%.
2021-06-11 00:20:27 +01:00
: NativeFunction(*static_cast<Object*>(global_object.error_constructor())) \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
{ \
} \
\
void ConstructorName::initialize(GlobalObject& global_object) \
{ \
auto& vm = this->vm(); \
NativeFunction::initialize(global_object); \
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
\
/* 20.5.6.2.1 NativeError.prototype, \
https://tc39.es/ecma262/#sec-nativeerror.prototype */ \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
define_property(vm.names.prototype, global_object.snake_name##_prototype(), 0); \
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
\
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
define_property(vm.names.length, Value(1), Attribute::Configurable); \
} \
\
ConstructorName::~ConstructorName() { } \
\
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
/* 20.5.6.1.1 NativeError ( message ), https://tc39.es/ecma262/#sec-nativeerror */ \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
Value ConstructorName::call() \
{ \
return construct(*this); \
} \
\
LibJS: Add a bunch more missing ECMA-262 section/title/URL comments
2021-06-19 00:38:41 +01:00
/* 20.5.6.1.1 NativeError ( message ), https://tc39.es/ecma262/#sec-nativeerror */ \
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Value ConstructorName::construct(FunctionObject& new_target) \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
{ \
auto& vm = this->vm(); \
LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors Resolves various FIXMEs :^)
2021-06-20 01:09:39 +01:00
auto& global_object = this->global_object(); \
\
auto* error = ordinary_create_from_constructor<ClassName>( \
global_object, new_target, &GlobalObject::snake_name##_prototype); \
if (vm.exception()) \
return {}; \
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
\
u8 attr = Attribute::Writable | Attribute::Configurable; \
\
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
if (!vm.argument(0).is_undefined()) { \
LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors Resolves various FIXMEs :^)
2021-06-20 01:09:39 +01:00
auto message = vm.argument(0).to_string(global_object); \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
if (vm.exception()) \
return {}; \
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
error->define_property(vm.names.message, js_string(vm, message), attr); \
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-12 00:08:28 +02:00
} \
LibJS: Implement the Error Cause proposal Currently stage 3. https://github.com/tc39/proposal-error-cause
2021-06-11 20:40:08 +01:00
\
error->install_error_cause(vm.argument(1)); \
if (vm.exception()) \
return {}; \
\
return error; \
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 12:42:33 +02:00
}
LibJS: Rename JS_ENUMERATE_{ERROR_SUBCLASSES => NATIVE_ERRORS} The fact that they *are* subclasses is an implementation detail and should not be highlighted. The spec calls these NativeErrors, so let's use that. Also added a comment explaining *why* they inherit from Error - I was about to change that :^)
2021-06-11 17:54:42 +01:00
JS_ENUMERATE_NATIVE_ERRORS
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
#undef __JS_ENUMERATE
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 12:42:33 +02:00
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
}
Reference in a new issue Copy permalink