Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/ProxyConstructor.cpp

81 lines
2.9 KiB
C++
Raw Normal View History

LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
/*
* Copyright (c) 2020, Matthew Olsson <matthewcolsson@gmail.com>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <LibJS/Interpreter.h>
#include <LibJS/Runtime/Array.h>
#include <LibJS/Runtime/Error.h>
#include <LibJS/Runtime/GlobalObject.h>
#include <LibJS/Runtime/ProxyConstructor.h>
#include <LibJS/Runtime/ProxyObject.h>
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
ProxyConstructor::ProxyConstructor(GlobalObject& global_object)
: NativeFunction("Proxy", *global_object.function_prototype())
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07: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 ProxyConstructor::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: 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: 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
define_property("prototype", global_object.proxy_prototype(), 0);
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
define_property("length", Value(2), Attribute::Configurable);
}
ProxyConstructor::~ProxyConstructor()
{
}
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 ProxyConstructor::call()
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
{
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
vm().throw_exception<TypeError>(global_object(), ErrorType::ProxyCallWithNew);
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07: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
Value ProxyConstructor::construct(Function&)
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07: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();
if (vm.argument_count() < 2) {
vm.throw_exception<TypeError>(global_object(), ErrorType::ProxyTwoArguments);
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07: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 target = vm.argument(0);
auto handler = vm.argument(1);
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
if (!target.is_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
vm.throw_exception<TypeError>(global_object(), ErrorType::ProxyConstructorBadType, "target", target.to_string_without_side_effects().characters());
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
if (!handler.is_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
vm.throw_exception<TypeError>(global_object(), ErrorType::ProxyConstructorBadType, "handler", handler.to_string_without_side_effects().characters());
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
return ProxyObject::create(global_object(), target.as_object(), handler.as_object());
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
}
}
Reference in a new issue Copy permalink