Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/GlobalObject.cpp

687 lines
32 KiB
C++
Raw Normal View History

Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
LibJS: Pass this value to fallback func in Array.prototype.toString() The existing code looks innocently correct, implementing the following step: 3. If IsCallable(func) is false, set func to the intrinsic function %Object.prototype.toString%. as return ObjectPrototype::to_string(vm, global_object); However, this misses the fact that the next step calls the function with the previously ToObject()'d this value (`array`): 4. Return ? Call(func, array). This doesn't happen in the current implementation, which will use the unaltered this value from the Array.prototype.toString() call, and make another, unequal object in %Object.prototype.toString%. Since both that and Array.prototype.toString() do a Get() call on said object, this behavior is observable (see newly added test). Fix this by actually doing what the spec says and calling the fallback function the regular way.
2022-04-11 22:47:50 +01:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02: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
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
*/
AK+Everywhere: Replace __builtin bit functions In order to reduce our reliance on __builtin_{ffs, clz, ctz, popcount}, this commit removes all calls to these functions and replaces them with the equivalent functions in AK/BuiltinWrappers.h.
2021-12-19 15:46:55 -06:00
#include <AK/BuiltinWrappers.h>
Everywhere: Replace ctype.h to avoid narrowing conversions This replaces ctype.h with CharacterType.h everywhere I could find issues with narrowing conversions. While using it will probably make sense almost everywhere in the future, the most critical places should have been addressed.
2021-06-01 21:18:08 +02:00
#include <AK/CharacterTypes.h>
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
#include <AK/Hex.h>
#include <AK/Platform.h>
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
#include <AK/UnicodeUtils.h>
LibJS: Correcly handle surrogates in escape() Fixes test/annexB/built-ins/escape/escape-above{,-astral}.js in test262. All tests in test/annexB/built-ins/escape pass now.
2022-01-13 19:45:11 -05:00
#include <AK/Utf16View.h>
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
#include <AK/Utf8View.h>
LibJS: Move Console from Interpreter to GlobalObject Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29 21:15:06 +02:00
#include <LibJS/Console.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#include <LibJS/Heap/DeferGC.h>
LibJS: Add naive implementation of eval() :^) This parses and executes a code string in the caller's lexical scope.
2021-03-14 16:20:01 +01:00
#include <LibJS/Interpreter.h>
LibJS: Correct behaviour of direct vs. indirect eval eval only has direct access to the local scope when accessed through the name eval. This includes locals named eval, because of course it does.
2021-06-19 20:13:53 -07:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Implement AggregateError
2021-06-11 18:06:20 +01:00
#include <LibJS/Runtime/AggregateErrorConstructor.h>
#include <LibJS/Runtime/AggregateErrorPrototype.h>
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
#include <LibJS/Runtime/ArrayBufferConstructor.h>
#include <LibJS/Runtime/ArrayBufferPrototype.h>
LibJS: Add basic Array constructor We only support Array() with 0 or 1 parameters so far.
2020-04-04 22:28:21 +02:00
#include <LibJS/Runtime/ArrayConstructor.h>
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
#include <LibJS/Runtime/ArrayIteratorPrototype.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/ArrayPrototype.h>
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
#include <LibJS/Runtime/AsyncFromSyncIteratorPrototype.h>
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
#include <LibJS/Runtime/AsyncFunctionConstructor.h>
#include <LibJS/Runtime/AsyncFunctionPrototype.h>
LibJS: Parse async generator functions
2021-11-15 01:53:24 +01:00
#include <LibJS/Runtime/AsyncGeneratorFunctionConstructor.h>
#include <LibJS/Runtime/AsyncGeneratorFunctionPrototype.h>
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
#include <LibJS/Runtime/AsyncGeneratorPrototype.h>
LibJS: Add AsyncIteratorPrototype
2021-11-23 14:53:02 +01:00
#include <LibJS/Runtime/AsyncIteratorPrototype.h>
LibJS: Begin implementing Atomics This adds the Atomics object to the global object and sets up only its @@toStringTag property.
2021-07-10 22:53:54 -04:00
#include <LibJS/Runtime/AtomicsObject.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibJS/Runtime/BigIntConstructor.h>
#include <LibJS/Runtime/BigIntPrototype.h>
LibJS: Add Boolean constructor object
2020-04-06 22:51:16 -05:00
#include <LibJS/Runtime/BooleanConstructor.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/BooleanPrototype.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/ConsoleObject.h>
LibJS: Add the DataView built-in object
2021-06-14 01:47:08 +03:00
#include <LibJS/Runtime/DataViewConstructor.h>
#include <LibJS/Runtime/DataViewPrototype.h>
LibJS: Start implementing Date :^) This adds: - A global Date object (with `length` property and `now` function) - The Date constructor (no arguments yet) - The Date prototype (with `get*` functions)
2020-03-30 00:21:56 +01:00
#include <LibJS/Runtime/DateConstructor.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/DatePrototype.h>
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
#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/ErrorPrototype.h>
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
#include <LibJS/Runtime/FinalizationRegistryConstructor.h>
#include <LibJS/Runtime/FinalizationRegistryPrototype.h>
LibJS: Add Function() and Function.prototype
2020-04-04 14:34:31 +01:00
#include <LibJS/Runtime/FunctionConstructor.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/FunctionPrototype.h>
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
#include <LibJS/Runtime/GeneratorFunctionConstructor.h>
#include <LibJS/Runtime/GeneratorFunctionPrototype.h>
LibJS: Rename GeneratorObjectPrototype to GeneratorPrototype Given we usually call objects Foo{Object,Constructor,Prototype} or Foo{,Constructor,Prototype}, this name was an odd choice. The new one matches the spec better, which calls it the "Generator Prototype Object", so we simply omit the Object suffix as usual as it's implied.
2022-01-16 14:14:42 +01:00
#include <LibJS/Runtime/GeneratorPrototype.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/GlobalEnvironment.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement a nearly empty Intl.Collator object This adds plumbing for the Intl.Collator object, constructor, and prototype.
2021-09-06 22:18:48 -04:00
#include <LibJS/Runtime/Intl/CollatorConstructor.h>
#include <LibJS/Runtime/Intl/CollatorPrototype.h>
LibJS: Implement a nearly empty Intl.DateTimeFormat object This adds plumbing for the Intl.DateTimeFormat object, constructor, and prototype. Note that unlike other Intl objects, the Intl.DateTimeFormat object has a LibUnicode structure as a base. This is to prevent wild amounts of code duplication between LibUnicode, Intl.DateTimeFormat, and other not-yet-defined Intl structures, because there's 12 fields shared between them.
2021-11-18 10:30:31 -05:00
#include <LibJS/Runtime/Intl/DateTimeFormatConstructor.h>
#include <LibJS/Runtime/Intl/DateTimeFormatPrototype.h>
LibJS: Implement a nearly empty Intl.DisplayNames object This adds plumbing for the Intl.DisplayNames object, constructor, and prototype.
2021-08-24 22:27:05 -04:00
#include <LibJS/Runtime/Intl/DisplayNamesConstructor.h>
#include <LibJS/Runtime/Intl/DisplayNamesPrototype.h>
LibJS: Start implementing the stage 3 Intl.DurationFormat proposal
2022-06-30 00:58:40 +03:00
#include <LibJS/Runtime/Intl/DurationFormatConstructor.h>
#include <LibJS/Runtime/Intl/DurationFormatPrototype.h>
LibJS: Add the Intl namespace object :^) This is the start of implementing ECMA-402 in LibJS, better known as the ECMAScript Internationalization API. Much like Temporal this gets its own subdirectory (Runtime/Intl/) as well as a new C++ namespace (JS::Intl) so we don't have to prefix all the files and classes with "Intl". https://tc39.es/ecma402/
2021-08-08 18:27:28 +01:00
#include <LibJS/Runtime/Intl/Intl.h>
LibJS: Implement a nearly empty Intl.ListFormat object This adds plumbing for the Intl.ListFormat object, constructor, and prototype.
2021-09-05 23:05:16 -04:00
#include <LibJS/Runtime/Intl/ListFormatConstructor.h>
#include <LibJS/Runtime/Intl/ListFormatPrototype.h>
LibJS: Implement a nearly empty Intl.Locale object This adds plumbing for the Intl.Locale object, constructor, and prototype.
2021-09-02 08:32:43 -04:00
#include <LibJS/Runtime/Intl/LocaleConstructor.h>
#include <LibJS/Runtime/Intl/LocalePrototype.h>
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
#include <LibJS/Runtime/Intl/NumberFormatConstructor.h>
#include <LibJS/Runtime/Intl/NumberFormatPrototype.h>
LibJS: Implement a nearly empty Intl.PluralRules object This adds plumbing for the Intl.PluralRules object, constructor, and prototype.
2022-01-28 12:56:04 -05:00
#include <LibJS/Runtime/Intl/PluralRulesConstructor.h>
#include <LibJS/Runtime/Intl/PluralRulesPrototype.h>
LibJS: Implement a nearly empty Intl.RelativeTimeFormat object This adds plumbing for the Intl.RelativeTimeFormat object, constructor, and prototype.
2022-01-25 10:41:57 -05:00
#include <LibJS/Runtime/Intl/RelativeTimeFormatConstructor.h>
#include <LibJS/Runtime/Intl/RelativeTimeFormatPrototype.h>
LibJS: Start implementing Intl Segment Iterator objects
2022-01-30 02:18:47 +02:00
#include <LibJS/Runtime/Intl/SegmentIteratorPrototype.h>
LibJS: Start implementing Intl.Segmenter
2022-01-29 23:47:29 +02:00
#include <LibJS/Runtime/Intl/SegmenterConstructor.h>
#include <LibJS/Runtime/Intl/SegmenterPrototype.h>
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +02:00
#include <LibJS/Runtime/Intl/SegmentsPrototype.h>
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
#include <LibJS/Runtime/IteratorPrototype.h>
LibJS: Add JSON.stringify
2020-06-10 11:01:00 -07:00
#include <LibJS/Runtime/JSONObject.h>
LibJS: Add the Map built-in object
2021-06-12 23:54:40 +03:00
#include <LibJS/Runtime/MapConstructor.h>
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
#include <LibJS/Runtime/MapIteratorPrototype.h>
LibJS: Add the Map built-in object
2021-06-12 23:54:40 +03:00
#include <LibJS/Runtime/MapPrototype.h>
LibJS: Add Math.random() :^)
2020-03-21 17:52:12 +01:00
#include <LibJS/Runtime/MathObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Add Number()
2020-04-07 16:17:23 +01:00
#include <LibJS/Runtime/NumberConstructor.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/NumberPrototype.h>
#include <LibJS/Runtime/Object.h>
LibJS: Add a global "Object" constructor This patch adds an "Object" constructor to the global object. The only function it implements so far is Object.getPrototypeOf().
2020-03-28 17:23:54 +01:00
#include <LibJS/Runtime/ObjectConstructor.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/ObjectPrototype.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <LibJS/Runtime/PromiseConstructor.h>
#include <LibJS/Runtime/PromisePrototype.h>
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
#include <LibJS/Runtime/ProxyConstructor.h>
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
#include <LibJS/Runtime/Realm.h>
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
#include <LibJS/Runtime/ReflectObject.h>
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
#include <LibJS/Runtime/RegExpConstructor.h>
#include <LibJS/Runtime/RegExpPrototype.h>
LibJS: Implement the RegExpStringIterator object This implementation closely follows the StringIterator object in that the abstract closure meant to be created in CreateRegExpStringIterator is instead unrolled into RegExpStringIterator.prototype.next.
2021-07-15 08:58:27 -04:00
#include <LibJS/Runtime/RegExpStringIteratorPrototype.h>
LibJS: Add the Set built-in object
2021-06-09 00:08:47 +03:00
#include <LibJS/Runtime/SetConstructor.h>
LibJS: Add the SetIterator built-in and Set.prototype.{values, entries} While this implementation should be complete it is based on HashTable's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashTable member in Set with an enhanced one that maintains a linked list in insertion order.
2021-06-09 00:17:17 +03:00
#include <LibJS/Runtime/SetIteratorPrototype.h>
LibJS: Add the Set built-in object
2021-06-09 00:08:47 +03:00
#include <LibJS/Runtime/SetPrototype.h>
LibJS: Start implementing ShadowRealm This commit adds the ShadowRealm object itself, its constructor, and prototype (currently empty).
2021-10-13 21:09:45 +01:00
#include <LibJS/Runtime/ShadowRealmConstructor.h>
#include <LibJS/Runtime/ShadowRealmPrototype.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/Shape.h>
LibJS: Add String constructor :^)
2020-04-10 14:14:02 +02:00
#include <LibJS/Runtime/StringConstructor.h>
LibJS: Add StringIterator
2020-07-11 20:23:01 -07:00
#include <LibJS/Runtime/StringIteratorPrototype.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/StringPrototype.h>
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
#include <LibJS/Runtime/SymbolConstructor.h>
#include <LibJS/Runtime/SymbolPrototype.h>
LibJS: Start implementing Temporal.Calendar Just like the previous Temporal.{Instant,TimeZone} commits, this patch adds the Calendar object itself, its constructor and prototype (currently empty), and two required abstract operations.
2021-07-14 21:01:12 +01:00
#include <LibJS/Runtime/Temporal/CalendarConstructor.h>
#include <LibJS/Runtime/Temporal/CalendarPrototype.h>
LibJS: Start implementing Temporal.Duration This patch adds the Duration object itself, its constructor and prototype (currently empty), and three required abstract operations.
2021-07-15 23:20:43 +01:00
#include <LibJS/Runtime/Temporal/DurationConstructor.h>
#include <LibJS/Runtime/Temporal/DurationPrototype.h>
LibJS: Start implementing Temporal.Instant Just like the initial Temporal.TimeZone commit, this patch adds the Instant object itself, its constructor and prototype (currently empty), and two required abstract operations.
2021-07-07 17:41:37 +01:00
#include <LibJS/Runtime/Temporal/InstantConstructor.h>
#include <LibJS/Runtime/Temporal/InstantPrototype.h>
LibJS: Start implementing Temporal.PlainDate This commit adds the PlainDate object itself, its constructor and prototype (currently empty), and several required abstract operations.
2021-07-19 00:29:26 +03:00
#include <LibJS/Runtime/Temporal/PlainDateConstructor.h>
#include <LibJS/Runtime/Temporal/PlainDatePrototype.h>
LibJS: Start implementing Temporal.PlainDateTime This commit adds the PlainDateTime object itself, its constructor and prototype (currently empty), and the CreateTemporalDateTime abstract operation.
2021-07-22 19:47:07 +01:00
#include <LibJS/Runtime/Temporal/PlainDateTimeConstructor.h>
#include <LibJS/Runtime/Temporal/PlainDateTimePrototype.h>
LibJS: Start implementing Temporal.PlainMonthDay This commit adds the PlainMonthDay object itself, its constructor and prototype (currently empty), and the CreateTemporalMonthDay abstract operations.
2021-08-14 23:54:24 +01:00
#include <LibJS/Runtime/Temporal/PlainMonthDayConstructor.h>
#include <LibJS/Runtime/Temporal/PlainMonthDayPrototype.h>
LibJS: Start implementing Temporal.PlainTime This commit adds the PlainTime object itself, its constructor and prototype (currently empty), and the CreateTemporalTime abstract operation.
2021-07-28 18:36:52 +01:00
#include <LibJS/Runtime/Temporal/PlainTimeConstructor.h>
#include <LibJS/Runtime/Temporal/PlainTimePrototype.h>
LibJS: Start implementing Temporal.PlainYearMonth This commit adds the PlainYearMonth object itself, its constructor and prototype (currently empty), and the CreateTemporalYearMonth and ISOYearMonthWithinLimits abstract operations.
2021-08-07 22:40:32 +01:00
#include <LibJS/Runtime/Temporal/PlainYearMonthConstructor.h>
#include <LibJS/Runtime/Temporal/PlainYearMonthPrototype.h>
LibJS: Add the Temporal namespace object :^) Currently empty, but we gotta start somewhere! This is the start of implementing the Temporal proposal (currently stage 3). I have decided to start a new subdirectory (Runtime/Temporal/) as well as a new C++ namespace (JS::Temporal) for this so we don't have to prefix all the files and classes with "Temporal" - there will be a lot. https://tc39.es/proposal-temporal/
2021-07-06 19:14:47 +01:00
#include <LibJS/Runtime/Temporal/Temporal.h>
LibJS: Start implementing Temporal.TimeZone Here we got our first Temporal object :^) This patch adds the TimeZone object itself, its constructor and prototype (currently empty), and a bunch of required abstract operations
2021-07-06 23:53:27 +01:00
#include <LibJS/Runtime/Temporal/TimeZoneConstructor.h>
#include <LibJS/Runtime/Temporal/TimeZonePrototype.h>
LibJS: Start implementing Temporal.ZonedDateTime This commit adds the ZonedDateTime object itself, its constructor and prototype (currently empty), and the CreateTemporalZonedDateTime abstract operation.
2021-08-01 17:20:11 +01:00
#include <LibJS/Runtime/Temporal/ZonedDateTimeConstructor.h>
#include <LibJS/Runtime/Temporal/ZonedDateTimePrototype.h>
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
#include <LibJS/Runtime/TypedArray.h>
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
#include <LibJS/Runtime/TypedArrayConstructor.h>
#include <LibJS/Runtime/TypedArrayPrototype.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Add the WeakMap built-in object
2021-06-12 05:28:30 +03:00
#include <LibJS/Runtime/WeakMapConstructor.h>
#include <LibJS/Runtime/WeakMapPrototype.h>
LibJS: Add the WeakRef built-in object
2021-06-12 17:38:34 +03:00
#include <LibJS/Runtime/WeakRefConstructor.h>
#include <LibJS/Runtime/WeakRefPrototype.h>
LibJS: Add the WeakSet built-in object
2021-06-09 19:23:04 +03:00
#include <LibJS/Runtime/WeakSetConstructor.h>
#include <LibJS/Runtime/WeakSetPrototype.h>
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
namespace JS {
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
GlobalObject::GlobalObject(Realm& realm)
: Object(GlobalObjectTag::Tag, realm)
LibJS: Move Console from Interpreter to GlobalObject Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29 21:15:06 +02:00
, m_console(make<Console>(*this))
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
{
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
}
LibJS: Rename GlobalObject::initialize() => initialize_global_object() This function was shadowing Object::initialize() which cannot be called on global objects and has a different set of parameters.
2021-03-17 16:52:26 +01:00
void GlobalObject::initialize_global_object()
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
{
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: Make global objects have unique shape from the start There's no point in trying to achieve shape sharing for global objects, so we can simply make the shape unique from the start and avoid making a transition chain.
2020-10-04 22:56:45 +02:00
ensure_shape_is_unique();
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
// These are done first since other prototypes depend on their presence.
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
VERIFY(associated_realm());
auto& realm = *associated_realm();
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_empty_object_shape = heap().allocate_without_realm<Shape>(realm);
m_object_prototype = heap().allocate_without_realm<ObjectPrototype>(realm);
m_function_prototype = heap().allocate_without_realm<FunctionPrototype>(realm);
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
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_new_object_shape = vm.heap().allocate_without_realm<Shape>(realm);
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
m_new_object_shape->set_prototype_without_transition(m_object_prototype);
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_new_ordinary_function_prototype_object_shape = vm.heap().allocate_without_realm<Shape>(realm);
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
m_new_ordinary_function_prototype_object_shape->set_prototype_without_transition(m_object_prototype);
m_new_ordinary_function_prototype_object_shape->add_property_without_transition(vm.names.constructor, Attribute::Writable | Attribute::Configurable);
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
// Normally Heap::allocate() takes care of this, but these are allocated via allocate_without_realm().
LibJS+LibWeb: Replace GlobalObject with Realm in initialize() functions This is a continuation of the previous commit. Calling initialize() is the first thing that's done after allocating a cell on the JS heap - and in the common case of allocating an object, that's where properties are assigned and intrinsics occasionally accessed. Since those are supposed to live on the realm eventually, this is another step into that direction.
2022-08-16 00:20:49 +01:00
static_cast<FunctionPrototype*>(m_function_prototype)->initialize(realm);
static_cast<ObjectPrototype*>(m_object_prototype)->initialize(realm);
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
LibJS+LibWeb: Use Object::set_prototype() in more places
2021-10-02 14:32:37 +01:00
Object::set_prototype(m_object_prototype);
LibJS: Set prototype of GlobalObject to ObjectPrototype As the global object is constructed and initialized in a different way than most other objects we were not setting its prototype! This made things like "globalThis.toString()" fail unexpectedly.
2020-11-06 18:56:54 +00:00
LibJS: Implement AggregateError
2021-06-11 18:06:20 +01:00
// This must be initialized before allocating AggregateErrorPrototype, which uses ErrorPrototype as its prototype.
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_error_prototype = heap().allocate<ErrorPrototype>(realm, realm);
LibJS: Implement AggregateError
2021-06-11 18:06:20 +01:00
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#define __JS_ENUMERATE(ClassName, snake_name) \
if (!m_##snake_name##_prototype) \
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_##snake_name##_prototype = heap().allocate<ClassName##Prototype>(realm, realm);
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
// These must be initialized separately as they have no companion constructor
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_async_from_sync_iterator_prototype = heap().allocate<AsyncFromSyncIteratorPrototype>(realm, realm);
m_async_generator_prototype = heap().allocate<AsyncGeneratorPrototype>(realm, realm);
m_generator_prototype = heap().allocate<GeneratorPrototype>(realm, realm);
m_intl_segments_prototype = heap().allocate<Intl::SegmentsPrototype>(realm, realm);
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +02:00
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
if (!m_##snake_name##_prototype) \
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_##snake_name##_prototype = heap().allocate<PrototypeName>(realm, realm);
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 18:35:29 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
if (!m_intl_##snake_name##_prototype) \
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_intl_##snake_name##_prototype = heap().allocate<Intl::PrototypeName>(realm, realm);
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 18:35:29 +01:00
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
// Must be allocated before `Intl::Intl` below.
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
initialize_constructor(vm.names.ClassName, m_intl_##snake_name##_constructor, m_intl_##snake_name##_prototype);
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
if (!m_temporal_##snake_name##_prototype) \
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
m_temporal_##snake_name##_prototype = heap().allocate<Temporal::PrototypeName>(realm, realm);
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
// Must be allocated before `Temporal::Temporal` below.
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
initialize_constructor(vm.names.ClassName, m_temporal_##snake_name##_constructor, m_temporal_##snake_name##_prototype);
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Implement correct attributes for (almost) all properties Added the ability to include a u8 attributes parameter with all of the various put methods in the Object class. They can be omitted, in which case it defaults to "Writable | Enumerable | Configurable", just like before this commit. All of the attribute values for each property were gathered from SpiderMonkey in the Firefox console. Some properties (e.g. all of the canvas element properties) have undefined property descriptors... not quite sure what that means. Those were left as the default specified above.
2020-04-27 23:05:02 -07:00
u8 attr = Attribute::Writable | Attribute::Configurable;
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
define_native_function(vm.names.gc, gc, 0, attr);
define_native_function(vm.names.isNaN, is_nan, 1, attr);
define_native_function(vm.names.isFinite, is_finite, 1, attr);
define_native_function(vm.names.parseFloat, parse_float, 1, attr);
define_native_function(vm.names.parseInt, parse_int, 2, attr);
define_native_function(vm.names.eval, eval, 1, attr);
LibJS: Correct behaviour of direct vs. indirect eval eval only has direct access to the local scope when accessed through the name eval. This includes locals named eval, because of course it does.
2021-06-19 20:13:53 -07:00
LibJS: Add and use the %ThrowTypeError% intrinsic
2021-06-28 03:53:35 +03:00
// 10.2.4.1 %ThrowTypeError% ( ), https://tc39.es/ecma262/#sec-%throwtypeerror%
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
m_throw_type_error_function = NativeFunction::create(
realm, [](VM& vm, GlobalObject& global_object) {
return vm.throw_completion<TypeError>(global_object, ErrorType::RestrictedFunctionPropertiesAccess);
},
0, "", &realm);
LibJS: Remove transition avoidance & start caching prototype transitions The way that transition avoidance (foo_without_transition) was implemented led to shapes being unshareable and caused shape explosion instead, precisely what we were trying to avoid. This patch removes all the attempts to avoid transitioning shapes, and instead *adds* transitions when changing an object's prototype. This makes transitions flow naturally, and as a result we end up with way fewer shape objects in real-world situations. When we run out of big problems, we can get back to avoiding transitions as an optimization, but for now, let's avoid ballooning our processes with a unique shape for every object.
2021-10-01 02:43:57 +02:00
m_throw_type_error_function->define_direct_property(vm.names.length, Value(0), 0);
m_throw_type_error_function->define_direct_property(vm.names.name, js_string(vm, ""), 0);
LibJS: Use MUST() where applicable
2021-10-03 15:57:26 +01:00
MUST(m_throw_type_error_function->internal_prevent_extensions());
LibJS: Add and use the %ThrowTypeError% intrinsic
2021-06-28 03:53:35 +03:00
// 10.2.4 AddRestrictedFunctionProperties ( F, realm ), https://tc39.es/ecma262/#sec-addrestrictedfunctionproperties
LibJS: Remove transition avoidance & start caching prototype transitions The way that transition avoidance (foo_without_transition) was implemented led to shapes being unshareable and caused shape explosion instead, precisely what we were trying to avoid. This patch removes all the attempts to avoid transitioning shapes, and instead *adds* transitions when changing an object's prototype. This makes transitions flow naturally, and as a result we end up with way fewer shape objects in real-world situations. When we run out of big problems, we can get back to avoiding transitions as an optimization, but for now, let's avoid ballooning our processes with a unique shape for every object.
2021-10-01 02:43:57 +02:00
m_function_prototype->define_direct_accessor(vm.names.caller, m_throw_type_error_function, m_throw_type_error_function, Attribute::Configurable);
m_function_prototype->define_direct_accessor(vm.names.arguments, m_throw_type_error_function, m_throw_type_error_function, Attribute::Configurable);
LibJS: Add and use the %ThrowTypeError% intrinsic
2021-06-28 03:53:35 +03:00
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
define_native_function(vm.names.encodeURI, encode_uri, 1, attr);
define_native_function(vm.names.decodeURI, decode_uri, 1, attr);
define_native_function(vm.names.encodeURIComponent, encode_uri_component, 1, attr);
define_native_function(vm.names.decodeURIComponent, decode_uri_component, 1, attr);
define_native_function(vm.names.escape, escape, 1, attr);
define_native_function(vm.names.unescape, unescape, 1, attr);
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
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
define_direct_property(vm.names.NaN, js_nan(), 0);
define_direct_property(vm.names.Infinity, js_infinity(), 0);
define_direct_property(vm.names.undefined, js_undefined(), 0);
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
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
define_direct_property(vm.names.globalThis, this, attr);
LibJS+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion().
2022-08-16 00:20:50 +01:00
define_direct_property(vm.names.console, heap().allocate<ConsoleObject>(realm, realm), attr);
define_direct_property(vm.names.Atomics, heap().allocate<AtomicsObject>(realm, realm), attr);
define_direct_property(vm.names.Math, heap().allocate<MathObject>(realm, realm), attr);
define_direct_property(vm.names.JSON, heap().allocate<JSONObject>(realm, realm), attr);
define_direct_property(vm.names.Reflect, heap().allocate<ReflectObject>(realm, realm), attr);
define_direct_property(vm.names.Intl, heap().allocate<Intl::Intl>(realm, realm), attr);
define_direct_property(vm.names.Temporal, heap().allocate<Temporal::Temporal>(realm, realm), attr);
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
LibJS: Implement AggregateError
2021-06-11 18:06:20 +01:00
// This must be initialized before allocating AggregateErrorConstructor, which uses ErrorConstructor as its prototype.
initialize_constructor(vm.names.Error, m_error_constructor, m_error_prototype);
add_constructor(vm.names.AggregateError, m_aggregate_error_constructor, m_aggregate_error_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.Array, m_array_constructor, m_array_prototype);
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
add_constructor(vm.names.ArrayBuffer, m_array_buffer_constructor, m_array_buffer_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.BigInt, m_bigint_constructor, m_bigint_prototype);
add_constructor(vm.names.Boolean, m_boolean_constructor, m_boolean_prototype);
LibJS: Add the DataView built-in object
2021-06-14 01:47:08 +03:00
add_constructor(vm.names.DataView, m_data_view_constructor, m_data_view_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.Date, m_date_constructor, m_date_prototype);
add_constructor(vm.names.Error, m_error_constructor, m_error_prototype);
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
add_constructor(vm.names.FinalizationRegistry, m_finalization_registry_constructor, m_finalization_registry_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.Function, m_function_constructor, m_function_prototype);
LibJS: Add the Map built-in object
2021-06-12 23:54:40 +03:00
add_constructor(vm.names.Map, m_map_constructor, m_map_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.Number, m_number_constructor, m_number_prototype);
add_constructor(vm.names.Object, m_object_constructor, m_object_prototype);
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
add_constructor(vm.names.Promise, m_promise_constructor, m_promise_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.Proxy, m_proxy_constructor, nullptr);
add_constructor(vm.names.RegExp, m_regexp_constructor, m_regexp_prototype);
LibJS: Add the Set built-in object
2021-06-09 00:08:47 +03:00
add_constructor(vm.names.Set, m_set_constructor, m_set_prototype);
LibJS: Start implementing ShadowRealm This commit adds the ShadowRealm object itself, its constructor, and prototype (currently empty).
2021-10-13 21:09:45 +01:00
add_constructor(vm.names.ShadowRealm, m_shadow_realm_constructor, m_shadow_realm_prototype);
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.String, m_string_constructor, m_string_prototype);
add_constructor(vm.names.Symbol, m_symbol_constructor, m_symbol_prototype);
LibJS: Add the WeakMap built-in object
2021-06-12 05:28:30 +03:00
add_constructor(vm.names.WeakMap, m_weak_map_constructor, m_weak_map_prototype);
LibJS: Add the WeakRef built-in object
2021-06-12 17:38:34 +03:00
add_constructor(vm.names.WeakRef, m_weak_ref_constructor, m_weak_ref_prototype);
LibJS: Add the WeakSet built-in object
2021-06-09 19:23:04 +03:00
add_constructor(vm.names.WeakSet, m_weak_set_constructor, m_weak_set_prototype);
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: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
initialize_constructor(vm.names.TypedArray, m_typed_array_constructor, m_typed_array_prototype);
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
add_constructor(vm.names.ClassName, m_##snake_name##_constructor, m_##snake_name##_prototype);
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: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
JS_ENUMERATE_TYPED_ARRAYS
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
#undef __JS_ENUMERATE
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
LibJS: Add missing definition of AsyncFunction.prototype.constructor We also forgot to allocate an AsyncFunctionConstructor and assign it to m_async_function_constructor during GlobalObject initialization, whoops!
2022-01-19 19:42:45 +00:00
// NOTE: These constructors cannot be initialized with add_constructor as they have no global binding.
LibJS: Initialize {Async,}{Generator,}Function constructors properly We were previously manually initializing them instead of just calling GlobalObject::initialize_constructor, which aside from duplicating code also meant we didn't set the required name property.
2022-02-19 17:49:25 +02:00
initialize_constructor(vm.names.GeneratorFunction, m_generator_function_constructor, m_generator_function_prototype, Attribute::Configurable);
initialize_constructor(vm.names.AsyncGeneratorFunction, m_async_generator_function_constructor, m_async_generator_function_prototype, Attribute::Configurable);
initialize_constructor(vm.names.AsyncFunction, m_async_function_constructor, m_async_function_prototype, Attribute::Configurable);
LibJS: Parse async generator functions
2021-11-15 01:53:24 +01:00
LibJS: Fix value of Generator.prototype.constructor The spec says: 27.5.1.1 Generator.prototype.constructor https://tc39.es/ecma262/#sec-generator.prototype.constructor The initial value of Generator.prototype.constructor is %GeneratorFunction.prototype%. But we had it set to %GeneratorFunction% (the GeneratorFunction constructor).
2022-01-16 14:47:14 +01:00
// 27.5.1.1 Generator.prototype.constructor, https://tc39.es/ecma262/#sec-generator.prototype.constructor
m_generator_prototype->define_direct_property(vm.names.constructor, m_generator_function_prototype, Attribute::Configurable);
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
// 27.6.1.1 AsyncGenerator.prototype.constructor, https://tc39.es/ecma262/#sec-asyncgenerator-prototype-constructor
m_async_generator_prototype->define_direct_property(vm.names.constructor, m_async_generator_function_prototype, Attribute::Configurable);
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
m_array_prototype_values_function = &m_array_prototype->get_without_side_effects(vm.names.values).as_function();
LibJS: Add an accessor for the %Date.now% instrinsic property
2021-12-04 18:56:44 -05:00
m_date_constructor_now_function = &m_date_constructor->get_without_side_effects(vm.names.now).as_function();
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
m_eval_function = &get_without_side_effects(vm.names.eval).as_function();
LibJS: Expose JSON.parse as an intrinsic value of the global object This will allow us to safely call it if we need to parse JSON within LibJS.
2022-01-27 14:49:55 +01:00
m_json_parse_function = &get_without_side_effects(vm.names.JSON).as_object().get_without_side_effects(vm.names.parse).as_function();
LibJS: Pass this value to fallback func in Array.prototype.toString() The existing code looks innocently correct, implementing the following step: 3. If IsCallable(func) is false, set func to the intrinsic function %Object.prototype.toString%. as return ObjectPrototype::to_string(vm, global_object); However, this misses the fact that the next step calls the function with the previously ToObject()'d this value (`array`): 4. Return ? Call(func, array). This doesn't happen in the current implementation, which will use the unaltered this value from the Array.prototype.toString() call, and make another, unequal object in %Object.prototype.toString%. Since both that and Array.prototype.toString() do a Get() call on said object, this behavior is observable (see newly added test). Fix this by actually doing what the spec says and calling the fallback function the regular way.
2022-04-11 22:47:50 +01:00
m_object_prototype_to_string_function = &m_object_prototype->get_without_side_effects(vm.names.toString).as_function();
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01: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 10:25:06 -06:00
GlobalObject::~GlobalObject() = default;
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
LibJS: Rename Cell::visit_children() => Cell::visit_edges() The GC heap is really a graph of cells, so "children" didn't quite feel appropriate here.
2020-11-28 14:33:36 +01:00
void GlobalObject::visit_edges(Visitor& visitor)
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
{
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
Base::visit_edges(visitor);
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
visitor.visit(m_empty_object_shape);
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
visitor.visit(m_new_object_shape);
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
visitor.visit(m_new_ordinary_function_prototype_object_shape);
LibJS: Make sure GlobalObject marks the Proxy constructor
2020-12-08 13:32:15 +01:00
visitor.visit(m_proxy_constructor);
LibJS: Visit m_async_from_sync_iterator_prototype in GlobalObject This prevents random crashes in for async loops due to GC.
2022-01-30 00:33:15 +02:00
visitor.visit(m_async_from_sync_iterator_prototype);
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
visitor.visit(m_async_generator_prototype);
visitor.visit(m_generator_prototype);
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +02:00
visitor.visit(m_intl_segments_prototype);
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
visitor.visit(m_array_prototype_values_function);
LibJS: Add an accessor for the %Date.now% instrinsic property
2021-12-04 18:56:44 -05:00
visitor.visit(m_date_constructor_now_function);
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
visitor.visit(m_eval_function);
LibJS: Expose JSON.parse as an intrinsic value of the global object This will allow us to safely call it if we need to parse JSON within LibJS.
2022-01-27 14:49:55 +01:00
visitor.visit(m_json_parse_function);
LibJS: Pass this value to fallback func in Array.prototype.toString() The existing code looks innocently correct, implementing the following step: 3. If IsCallable(func) is false, set func to the intrinsic function %Object.prototype.toString%. as return ObjectPrototype::to_string(vm, global_object); However, this misses the fact that the next step calls the function with the previously ToObject()'d this value (`array`): 4. Return ? Call(func, array). This doesn't happen in the current implementation, which will use the unaltered this value from the Array.prototype.toString() call, and make another, unequal object in %Object.prototype.toString%. Since both that and Array.prototype.toString() do a Get() call on said object, this behavior is observable (see newly added test). Fix this by actually doing what the spec says and calling the fallback function the regular way.
2022-04-11 22:47:50 +01:00
visitor.visit(m_object_prototype_to_string_function);
visitor.visit(m_throw_type_error_function);
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
LibJS: GlobalObject must mark builtin prototypes Failing to mark them leads to use-after-free since the GlobalObject cached prototypes are used for new NumberObject, StringObject, etc. Found by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30319
2021-02-05 14:51:18 +01:00
visitor.visit(m_##snake_name##_constructor); \
visitor.visit(m_##snake_name##_prototype);
JS_ENUMERATE_BUILTIN_TYPES
LibJS: Use enumerator macro to mark all constructors in GlobalObject We were forgetting to mark the String constructor! So this patch fixes that and ensures we won't forget anyone in the future.
2020-04-18 11:02:05 +02:00
#undef __JS_ENUMERATE
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 18:35:29 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
visitor.visit(m_intl_##snake_name##_constructor); \
visitor.visit(m_intl_##snake_name##_prototype);
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
visitor.visit(m_temporal_##snake_name##_constructor); \
visitor.visit(m_temporal_##snake_name##_prototype);
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibJS: GlobalObject needs to mark the iterator prototypes Otherwise they all disappear in the first garbage collection.
2020-09-08 15:37:39 +02:00
#define __JS_ENUMERATE(ClassName, snake_name) \
visitor.visit(m_##snake_name##_prototype);
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
}
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
Realm* GlobalObject::associated_realm()
{
return m_associated_realm;
}
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
void GlobalObject::set_associated_realm(Realm& realm)
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
{
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
VERIFY(&realm == &shape().realm());
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
m_associated_realm = &realm;
}
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::gc)
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
{
LibJS: Hide gc() dbgln() behind #ifdef __serenity__ This spams to stdout when using Lagom, and is therefore included in test-js output. Don't need that.
2021-06-12 01:09:45 +01:00
#ifdef __serenity__
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
dbgln("Forced garbage collection requested!");
LibJS: Hide gc() dbgln() behind #ifdef __serenity__ This spams to stdout when using Lagom, and is therefore included in test-js output. Don't need that.
2021-06-12 01:09:45 +01:00
#endif
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
vm.heap().collect_garbage();
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
return js_undefined();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.3 isNaN ( number ), https://tc39.es/ecma262/#sec-isnan-number
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::is_nan)
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
return Value(TRY(vm.argument(0).to_number(global_object)).is_nan());
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.2 isFinite ( number ), https://tc39.es/ecma262/#sec-isfinite-number
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::is_finite)
LibJS: Add isFinite()
2020-04-22 18:07:24 +01:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
return Value(TRY(vm.argument(0).to_number(global_object)).is_finite_number());
LibJS: Add isFinite()
2020-04-22 18:07:24 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.4 parseFloat ( string ), https://tc39.es/ecma262/#sec-parsefloat-string
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::parse_float)
LibJS: Add parseFloat()
2020-05-17 15:12:34 +01:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
if (vm.argument(0).is_number())
return vm.argument(0);
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto input_string = TRY(vm.argument(0).to_string(global_object));
LibJS: Make parseFloat slightly more specification-compliant
2022-01-16 20:37:22 +02:00
auto trimmed_string = MUST(trim_string(global_object, js_string(vm, input_string), TrimMode::Left));
LibJS: Trim initial whitespace in parseFloat
2021-06-06 02:32:14 +03:00
for (size_t length = trimmed_string.length(); length > 0; --length) {
LibJS: Convert to_number() to ThrowCompletionOr
2021-10-17 23:20:05 +03:00
auto number = MUST(Value(js_string(vm, trimmed_string.substring(0, length))).to_number(global_object));
LibJS: Add parseFloat()
2020-05-17 15:12:34 +01:00
if (!number.is_nan())
return number;
}
return js_nan();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.5 parseInt ( string, radix ), https://tc39.es/ecma262/#sec-parseint-string-radix
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::parse_int)
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
{
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 1. Let inputString be ? ToString(string).
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto input_string = TRY(vm.argument(0).to_string(global_object));
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 2. Let S be ! TrimString(inputString, start).
auto string = MUST(trim_string(global_object, js_string(vm, input_string), TrimMode::Left));
// 3. Let sign be 1.
auto sign = 1;
// 4. If S is not empty and the first code unit of S is the code unit 0x002D (HYPHEN-MINUS), set sign to -1.
if (!string.is_empty() && string[0] == 0x2D)
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
sign = -1;
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 5. If S is not empty and the first code unit of S is the code unit 0x002B (PLUS SIGN) or the code unit 0x002D (HYPHEN-MINUS), remove the first code unit from S.
auto trimmed_view = string.view();
if (!string.is_empty() && (string[0] == 0x2B || string[0] == 0x2D))
trimmed_view = trimmed_view.substring_view(1);
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 6. Let R be ℝ(? ToInt32(radix)).
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto radix = TRY(vm.argument(1).to_i32(global_object));
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 7. Let stripPrefix be true.
auto strip_prefix = true;
// 8. If R ≠ 0, then
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
if (radix != 0) {
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// a. If R < 2 or R > 36, return NaN.
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
if (radix < 2 || radix > 36)
return js_nan();
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// b. If R ≠ 16, set stripPrefix to false.
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
if (radix != 16)
strip_prefix = false;
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
}
// 9. Else,
else {
// a. Set R to 10.
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
radix = 10;
}
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 10. If stripPrefix is true, then
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
if (strip_prefix) {
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// a. If the length of S is at least 2 and the first two code units of S are either "0x" or "0X", then
if (trimmed_view.length() >= 2 && trimmed_view.substring_view(0, 2).equals_ignoring_case("0x"sv)) {
// i. Remove the first two code units from S.
trimmed_view = trimmed_view.substring_view(2);
// ii. Set R to 16.
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
radix = 16;
}
}
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 11. If S contains a code unit that is not a radix-R digit, let end be the index within S of the first such code unit; otherwise, let end be the length of S.
// 12. Let Z be the substring of S from 0 to end.
// 13. If Z is empty, return NaN.
// 14. Let mathInt be the integer value that is represented by Z in radix-R notation, using the letters A-Z and a-z for digits with values 10 through 35. (However, if R is 10 and Z contains more than 20 significant digits, every significant digit after the 20th may be replaced by a 0 digit, at the option of the implementation; and if R is not 2, 4, 8, 10, 16, or 32, then mathInt may be an implementation-approximated integer representing the integer value denoted by Z in radix-R notation.)
auto parse_digit = [&](u32 code_point) -> Optional<u32> {
if (!is_ascii_alphanumeric(code_point))
Everywhere: Replace ctype.h to avoid narrowing conversions This replaces ctype.h with CharacterType.h everywhere I could find issues with narrowing conversions. While using it will probably make sense almost everywhere in the future, the most critical places should have been addressed.
2021-06-01 21:18:08 +02:00
return {};
LibJS: Parse digits with parse_ascii_base36_digit in parseInt This was accidentally replaced with parse_ascii_hex_digit in bc8d16ad28afb7436bfde1fd0a21faf73d652230 which caused radices above 16 (hex) to fail.
2021-06-06 02:29:29 +03:00
auto digit = parse_ascii_base36_digit(code_point);
Everywhere: Replace ctype.h to avoid narrowing conversions This replaces ctype.h with CharacterType.h everywhere I could find issues with narrowing conversions. While using it will probably make sense almost everywhere in the future, the most critical places should have been addressed.
2021-06-01 21:18:08 +02:00
if (digit >= (u32)radix)
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
return {};
return digit;
};
bool had_digits = false;
double number = 0;
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
for (auto code_point : Utf8View(trimmed_view)) {
auto digit = parse_digit(code_point);
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
if (!digit.has_value())
break;
had_digits = true;
number *= radix;
number += digit.value();
}
if (!had_digits)
return js_nan();
LibJS: Rewrite parseInt to be more specification-compliant
2022-01-16 20:35:26 +02:00
// 15. If mathInt = 0, then
// a. If sign = -1, return -0𝔽.
// b. Return +0𝔽.
// 16. Return 𝔽(sign × mathInt).
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
return Value(sign * number);
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.1 eval ( x ), https://tc39.es/ecma262/#sec-eval-x
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::eval)
LibJS: Add naive implementation of eval() :^) This parses and executes a code string in the caller's lexical scope.
2021-03-14 16:20:01 +01:00
{
LibJS: Remove callerRealm from HostEnsureCanCompileStrings This is a normative change in the ecma262 spec. See: https://github.com/tc39/ecma262/commit/2527be4
2022-04-22 19:10:27 +01:00
return perform_eval(global_object, vm.argument(0), CallerMode::NonStrict, EvalMode::Indirect);
LibJS: Add naive implementation of eval() :^) This parses and executes a code string in the caller's lexical scope.
2021-03-14 16:20:01 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.1.1 Encode ( string, unescapedSet ), https://tc39.es/ecma262/#sec-encode
LibJS: Remove a bunch of gratuitous JS namespace qualifiers
2022-04-03 15:19:33 +01:00
static ThrowCompletionOr<String> encode(GlobalObject& global_object, String const& string, StringView unescaped_set)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
auto& vm = global_object.vm();
auto utf16_string = Utf16String(string);
LibJS: Use consistent phrasing for string length This is an editorial change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/33ea99e
2022-05-03 21:37:01 +02:00
// 1. Let strLen be the length of string.
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
auto string_length = utf16_string.length_in_code_units();
// 2. Let R be the empty String.
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
StringBuilder encoded_builder;
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
// 3. Let k be 0.
auto k = 0u;
// 4. Repeat,
while (k < string_length) {
// a. If k = strLen, return R.
// Handled below
// b. Let C be the code unit at index k within string.
auto code_unit = utf16_string.code_unit_at(k);
// c. If C is in unescapedSet, then
// NOTE: We assume the unescaped set only contains ascii characters as unescaped_set is a StringView.
if (code_unit < 0x80 && unescaped_set.contains(code_unit)) {
// i. Set k to k + 1.
k++;
// ii. Set R to the string-concatenation of R and C.
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
encoded_builder.append(code_unit);
}
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
// d. Else,
else {
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// i. Let cp be CodePointAt(string, k).
LibJS: Rewrite the Encode AO to handle unpaired UTF-16 surrogates
2022-01-16 19:06:03 +02:00
auto code_point = code_point_at(utf16_string.view(), k);
// ii. If cp.[[IsUnpairedSurrogate]] is true, throw a URIError exception.
if (code_point.is_unpaired_surrogate)
return vm.throw_completion<URIError>(global_object, ErrorType::URIMalformed);
// iii. Set k to k + cp.[[CodeUnitCount]].
k += code_point.code_unit_count;
// iv. Let Octets be the List of octets resulting by applying the UTF-8 transformation to cp.[[CodePoint]].
// v. For each element octet of Octets, do
auto nwritten = AK::UnicodeUtils::code_point_to_utf8(code_point.code_point, [&encoded_builder](u8 octet) {
// 1. Set R to the string-concatenation of:
// * R
// * "%"
// * the String representation of octet, formatted as a two-digit uppercase hexadecimal number, padded to the left with a zero if necessary
encoded_builder.appendff("%{:02X}", octet);
});
VERIFY(nwritten > 0);
}
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
}
return encoded_builder.build();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.1.2 Decode ( string, reservedSet ), https://tc39.es/ecma262/#sec-decode
LibJS: Remove a bunch of gratuitous JS namespace qualifiers
2022-04-03 15:19:33 +01:00
static ThrowCompletionOr<String> decode(GlobalObject& global_object, String const& string, StringView reserved_set)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
StringBuilder decoded_builder;
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
auto code_point_start_offset = 0u;
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
auto expected_continuation_bytes = 0;
for (size_t k = 0; k < string.length(); k++) {
auto code_unit = string[k];
if (code_unit != '%') {
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
if (expected_continuation_bytes > 0)
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
decoded_builder.append(code_unit);
continue;
}
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
if (k + 2 >= string.length())
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
auto first_digit = decode_hex_digit(string[k + 1]);
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
if (first_digit >= 16)
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
auto second_digit = decode_hex_digit(string[k + 2]);
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
if (second_digit >= 16)
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
u8 decoded_code_unit = (first_digit << 4) | second_digit;
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
k += 2;
if (expected_continuation_bytes > 0) {
decoded_builder.append(decoded_code_unit);
expected_continuation_bytes--;
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
if (expected_continuation_bytes == 0 && !Utf8View(decoded_builder.string_view().substring_view(code_point_start_offset)).validate())
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
continue;
}
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
if ((decoded_code_unit & 0x80) == 0) {
if (reserved_set.contains(decoded_code_unit))
decoded_builder.append(string.substring_view(k - 2, 3));
else
decoded_builder.append(decoded_code_unit);
continue;
}
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
auto leading_ones = count_leading_zeroes_safe(static_cast<u8>(~decoded_code_unit));
LibJS: Convert GlobalObject's Encode and Decode AOs to ThrowCompletionOr
2021-10-29 17:02:06 -04:00
if (leading_ones == 1 || leading_ones > 4)
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
code_point_start_offset = decoded_builder.length();
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
decoded_builder.append(decoded_code_unit);
expected_continuation_bytes = leading_ones - 1;
}
LibJS: Check validity of encoded unicode code points in the Decode AO As required by the specification: 7. If Octets does not contain a valid UTF-8 encoding of a Unicode code point, throw a URIError exception.
2022-01-16 19:04:34 +02:00
if (expected_continuation_bytes > 0)
return global_object.vm().throw_completion<URIError>(global_object, ErrorType::URIMalformed);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
return decoded_builder.build();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.4 encodeURI ( uri ), https://tc39.es/ecma262/#sec-encodeuri-uri
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::encode_uri)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto uri_string = TRY(vm.argument(0).to_string(global_object));
auto encoded = TRY(encode(global_object, uri_string, ";/?:@&=+$,abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.!~*'()#"sv));
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
return js_string(vm, move(encoded));
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.2 decodeURI ( encodedURI ), https://tc39.es/ecma262/#sec-decodeuri-encodeduri
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::decode_uri)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto uri_string = TRY(vm.argument(0).to_string(global_object));
auto decoded = TRY(decode(global_object, uri_string, ";/?:@&=+$,#"sv));
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
return js_string(vm, move(decoded));
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.5 encodeURIComponent ( uriComponent ), https://tc39.es/ecma262/#sec-encodeuricomponent-uricomponent
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::encode_uri_component)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto uri_string = TRY(vm.argument(0).to_string(global_object));
auto encoded = TRY(encode(global_object, uri_string, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.!~*'()"sv));
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
return js_string(vm, move(encoded));
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 19.2.6.3 decodeURIComponent ( encodedURIComponent ), https://tc39.es/ecma262/#sec-decodeuricomponent-encodeduricomponent
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::decode_uri_component)
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto uri_string = TRY(vm.argument(0).to_string(global_object));
auto decoded = TRY(decode(global_object, uri_string, ""sv));
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
return js_string(vm, move(decoded));
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// B.2.1.1 escape ( string ), https://tc39.es/ecma262/#sec-escape-string
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::escape)
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto string = TRY(vm.argument(0).to_string(global_object));
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
StringBuilder escaped;
LibJS: Correcly handle surrogates in escape() Fixes test/annexB/built-ins/escape/escape-above{,-astral}.js in test262. All tests in test/annexB/built-ins/escape pass now.
2022-01-13 19:45:11 -05:00
for (auto code_point : utf8_to_utf16(string)) {
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
if (code_point < 256) {
if ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789@*_+-./"sv.contains(code_point))
escaped.append(code_point);
else
escaped.appendff("%{:02X}", code_point);
continue;
}
LibJS: Correcly handle surrogates in escape() Fixes test/annexB/built-ins/escape/escape-above{,-astral}.js in test262. All tests in test/annexB/built-ins/escape pass now.
2022-01-13 19:45:11 -05:00
escaped.appendff("%u{:04X}", code_point);
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
}
return js_string(vm, escaped.build());
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// B.2.1.2 unescape ( string ), https://tc39.es/ecma262/#sec-unescape-string
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DEFINE_NATIVE_FUNCTION(GlobalObject::unescape)
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
{
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
auto string = TRY(vm.argument(0).to_string(global_object));
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
ssize_t length = string.length();
StringBuilder unescaped(length);
for (auto k = 0; k < length; ++k) {
u32 code_point = string[k];
if (code_point == '%') {
if (k <= length - 6 && string[k + 1] == 'u' && is_ascii_hex_digit(string[k + 2]) && is_ascii_hex_digit(string[k + 3]) && is_ascii_hex_digit(string[k + 4]) && is_ascii_hex_digit(string[k + 5])) {
code_point = (parse_ascii_hex_digit(string[k + 2]) << 12) | (parse_ascii_hex_digit(string[k + 3]) << 8) | (parse_ascii_hex_digit(string[k + 4]) << 4) | parse_ascii_hex_digit(string[k + 5]);
k += 5;
} else if (k <= length - 3 && is_ascii_hex_digit(string[k + 1]) && is_ascii_hex_digit(string[k + 2])) {
code_point = (parse_ascii_hex_digit(string[k + 1]) << 4) | parse_ascii_hex_digit(string[k + 2]);
k += 2;
}
}
unescaped.append_code_point(code_point);
}
return js_string(vm, unescaped.build());
}
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
}
Reference in a new issue Copy permalink