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

46 lines
1.2 KiB
C++
Raw Normal View History

LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
/*
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 19:33:17 +00:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Add BigInt
2020-06-06 00:14:10 +00: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 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
*/
#include <LibCrypto/BigInt/SignedBigInteger.h>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
#include <LibGC/Heap.h>
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
#include <LibJS/Runtime/BigInt.h>
LibJS: Split out NumberToBigInt from the BigInt constructor This is supposed to be its own AO, but since it was only used in one place, we inlined it. Now that it's also being used in the Temporal proposal (Date.prototype.toTemporalInstant() specifically), it makes sense to have it as a standalone function. A small difference is that we now construct the SignedBigInteger without casting to i32 but instead take the (known to be integral) double and cast it to i64. Not perfect, but slightly better. Also clean up the BigInt constructor a bit while we're here and sprinkle some spec comments.
2021-07-07 23:30:56 +00:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
namespace JS {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
GC_DEFINE_ALLOCATOR(BigInt);
LibJS: Segregate GC-allocated objects by type This patch adds two macros to declare per-type allocators: - JS_DECLARE_ALLOCATOR(TypeName) - JS_DEFINE_ALLOCATOR(TypeName) When used, they add a type-specific CellAllocator that the Heap will delegate allocation requests to. The result of this is that GC objects of the same type always end up within the same HeapBlock, drastically reducing the ability to perform type confusion attacks. It also improves HeapBlock utilization, since each block now has cells sized exactly to the type used within that block. (Previously we only had a handful of block sizes available, and most GC allocations ended up with a large amount of slack in their tails.) There is a small performance hit from this, but I'm sure we can make up for it elsewhere. Note that the old size-based allocators still exist, and we fall back to them for any type that doesn't have its own CellAllocator.
2023-11-19 08:45:05 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
GC::Ref<BigInt> BigInt::create(VM& vm, Crypto::SignedBigInteger big_integer)
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
{
LibJS+LibWeb: Rename Heap::allocate_without_realm to Heap::allocate Now that the heap has no knowledge about a JavaScript realm and is purely for managing the memory of the heap, it does not make sense to name this function to say that it is a non-realm variant.
2024-11-13 17:13:46 +00:00
return vm.heap().allocate<BigInt>(move(big_integer));
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
}
LibJS: Replace standalone js_bigint() with BigInt::create() Three standalone Cell creation functions remain in the JS namespace: - js_bigint() - js_string() - js_symbol() All of them are leftovers from early iterations when LibJS still took inspiration from JSC, which itself has jsString(). Nowadays, we pretty much exclusively use static create() functions to construct types allocated on the JS heap, and there's no reason to not do the same for these. Also change the return type from BigInt* to NonnullGCPtr<BigInt> while we're here. This is patch 1/3, replacement of js_string() and js_symbol() follow.
2022-12-06 22:03:52 +00:00
BigInt::BigInt(Crypto::SignedBigInteger big_integer)
: m_big_integer(move(big_integer))
LibJS: Add a js_bigint(VM&, ...) overload and use it We already have js_string(VM&, ...) and js_symbol(VM&, ...) overloads, so feels very familiar.
2021-08-02 23:14:48 +00:00
{
LibJS: Replace standalone js_bigint() with BigInt::create() Three standalone Cell creation functions remain in the JS namespace: - js_bigint() - js_string() - js_symbol() All of them are leftovers from early iterations when LibJS still took inspiration from JSC, which itself has jsString(). Nowadays, we pretty much exclusively use static create() functions to construct types allocated on the JS heap, and there's no reason to not do the same for these. Also change the return type from BigInt* to NonnullGCPtr<BigInt> while we're here. This is patch 1/3, replacement of js_string() and js_symbol() follow.
2022-12-06 22:03:52 +00:00
VERIFY(!m_big_integer.is_invalid());
LibJS: Add a js_bigint(VM&, ...) overload and use it We already have js_string(VM&, ...) and js_symbol(VM&, ...) overloads, so feels very familiar.
2021-08-02 23:14:48 +00:00
}
LibJS: Define BigInt::to_string to complement to_deprecated_string
2023-02-13 02:03:11 +00:00
ErrorOr<String> BigInt::to_string() const
{
return String::formatted("{}n", TRY(m_big_integer.to_base(10)));
}
LibJS: Split out NumberToBigInt from the BigInt constructor This is supposed to be its own AO, but since it was only used in one place, we inlined it. Now that it's also being used in the Temporal proposal (Date.prototype.toTemporalInstant() specifically), it makes sense to have it as a standalone function. A small difference is that we now construct the SignedBigInteger without casting to i32 but instead take the (known to be integral) double and cast it to i64. Not perfect, but slightly better. Also clean up the BigInt constructor a bit while we're here and sprinkle some spec comments.
2021-07-07 23:30:56 +00:00
// 21.2.1.1.1 NumberToBigInt ( number ), https://tc39.es/ecma262/#sec-numbertobigint
LibJS: Replace GlobalObject with VM in remaining AOs [Part 19/19]
2022-08-21 19:38:35 +00:00
ThrowCompletionOr<BigInt*> number_to_bigint(VM& vm, Value number)
LibJS: Split out NumberToBigInt from the BigInt constructor This is supposed to be its own AO, but since it was only used in one place, we inlined it. Now that it's also being used in the Temporal proposal (Date.prototype.toTemporalInstant() specifically), it makes sense to have it as a standalone function. A small difference is that we now construct the SignedBigInteger without casting to i32 but instead take the (known to be integral) double and cast it to i64. Not perfect, but slightly better. Also clean up the BigInt constructor a bit while we're here and sprinkle some spec comments.
2021-07-07 23:30:56 +00:00
{
VERIFY(number.is_number());
// 1. If IsIntegralNumber(number) is false, throw a RangeError exception.
LibJS: Convert the NumberToBigInt AO to ThrowCompletionOr
2021-10-23 00:26:55 +00:00
if (!number.is_integral_number())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 19:33:17 +00:00
return vm.throw_completion<RangeError>(ErrorType::BigIntFromNonIntegral);
LibJS: Split out NumberToBigInt from the BigInt constructor This is supposed to be its own AO, but since it was only used in one place, we inlined it. Now that it's also being used in the Temporal proposal (Date.prototype.toTemporalInstant() specifically), it makes sense to have it as a standalone function. A small difference is that we now construct the SignedBigInteger without casting to i32 but instead take the (known to be integral) double and cast it to i64. Not perfect, but slightly better. Also clean up the BigInt constructor a bit while we're here and sprinkle some spec comments.
2021-07-07 23:30:56 +00:00
// 2. Return the BigInt value that represents ℝ(number).
LibJS: Replace standalone js_bigint() with BigInt::create() Three standalone Cell creation functions remain in the JS namespace: - js_bigint() - js_string() - js_symbol() All of them are leftovers from early iterations when LibJS still took inspiration from JSC, which itself has jsString(). Nowadays, we pretty much exclusively use static create() functions to construct types allocated on the JS heap, and there's no reason to not do the same for these. Also change the return type from BigInt* to NonnullGCPtr<BigInt> while we're here. This is patch 1/3, replacement of js_string() and js_symbol() follow.
2022-12-06 22:03:52 +00:00
return BigInt::create(vm, Crypto::SignedBigInteger { number.as_double() }).ptr();
LibJS: Split out NumberToBigInt from the BigInt constructor This is supposed to be its own AO, but since it was only used in one place, we inlined it. Now that it's also being used in the Temporal proposal (Date.prototype.toTemporalInstant() specifically), it makes sense to have it as a standalone function. A small difference is that we now construct the SignedBigInteger without casting to i32 but instead take the (known to be integral) double and cast it to i64. Not perfect, but slightly better. Also clean up the BigInt constructor a bit while we're here and sprinkle some spec comments.
2021-07-07 23:30:56 +00:00
}
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
}
Reference in a new issue Copy permalink