Commit graph

30 commits

Author SHA1 Message Date
MacDue
63b11030f0 Everywhere: Use ReadonlySpan<T> instead of Span<T const> 2023-02-08 19:15:45 +00:00
Timothy Flynn
f2527c8c81 LibJS: Add a fallible variant of Array::create_from 2023-01-24 16:23:50 -05:00
Linus Groh
91b0123eaf LibJS: Convert Array::create{,_from}() to NonnullGCPtr 2022-12-14 09:59:45 +00:00
Andreas Kling
35c9aa7c05 LibJS: Hide all the constructors!
Now that the GC allocator is able to invoke Cell subclass constructors
directly via friendship, we no longer need to keep them public. :^)
2022-08-29 03:24:54 +02:00
Andreas Kling
6e973ce69b LibJS: Add JS_CELL macro and use it in all JS::Cell subclasses
This is similar to what we already had with JS_OBJECT (and also
JS_ENVIRONMENT) but sits at the top of the Cell inheritance hierarchy.
2022-08-29 03:24:54 +02:00
Linus Groh
d69eaf8be9 LibJS: Replace GlobalObject with VM in Array AOs [Part 15/19] 2022-08-23 13:58:30 +01:00
Linus Groh
b99cc7d050 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-23 13:58:30 +01:00
Linus Groh
5927cdd9c5 LibJS: Use u64 for the length parameter in Array::create()
This doesn't matter per se as the value is immediately validated to be
in the 0 to 2^32 - 1 range, but it avoids having to cast a number that
potentially doesn't fit into a size_t into one at the call site. More
often than not, array-like lengths are only validated to be <= 2^52 - 1,
i.e. MAX_SAFE_INTEGER.

This is fully backwards compatible with existing code as a size_t always
fits into an u64, but an u64 might not always fit into a size_t.
2022-07-04 10:10:11 +02:00
Linus Groh
e2a5a27302 LibJS: Implement the SortIndexedProperties AO
Also use it in array_merge_sort() instead of inlining the algorithm.
2022-06-13 20:26:54 +01:00
Linus Groh
5ddf0b0c99 LibJS: Implement the CompareArrayElements AO 2022-06-13 20:26:54 +01:00
Lenny Maiorani
d00b79568f 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-16 16:19:40 +00:00
Linus Groh
bc183dbbcb LibJS: Replace uses of MarkedValueList with MarkedVector<Value>
This is effectively a drop-in replacement.
2022-02-09 12:25:27 +00:00
davidot
9264f9d24e LibJS+Everywhere: Remove VM::exception() and most related functions
This commit removes all exception related code:
Remove VM::exception(), VM::throw_exception() etc. Any leftover
throw_exception calls are moved to throw_completion.
The one method left is clear_exception() which is now a no-op. Most of
these calls are just to clear whatever exception might have been thrown
when handling a Completion. So to have a cleaner commit this will be
removed in a next commit.

It also removes the actual Exception and TemporaryClearException classes
since these are no longer used.

In any spot where the exception was actually used an attempt was made to
preserve that behavior. However since it is no longer tracked by the VM
we cannot access exceptions which were thrown in previous calls.
There are two such cases which might have different behavior:
- In Web::DOM::Document::interpreter() the on_call_stack_emptied hook
  used to print any uncaught exception but this is now no longer
  possible as the VM does not store uncaught exceptions.
- In js the code used to be interruptable by throwing an exception on
  the VM. This is no longer possible but was already somewhat fragile
  before as you could happen to throw an exception just before a VERIFY.
2022-02-08 09:12:42 +00:00
Timothy Flynn
98348d9a33 LibJS: Allow calling Array::create_from without allocating a Vector
This method works as-is with a Span instead of a Vector (with some minor
const correctness adjustments).
2022-01-31 00:32:41 +00:00
Andreas Kling
398c181c79 LibJS: Rename PropertyName to PropertyKey
Let's use the same name as the spec. :^)
2021-10-24 17:18:07 +02:00
Idan Horowitz
db5df26841 LibJS: Convert Array AOs to ThrowCompletionOr 2021-10-22 15:07:04 +03:00
Linus Groh
ee8380edea LibJS: Convert internal_own_property_keys() to ThrowCompletionOr 2021-09-29 23:49:53 +01:00
Linus Groh
fbfb0bb908 LibJS: Convert internal_delete() to ThrowCompletionOr 2021-09-29 23:49:53 +01:00
Linus Groh
5da210125e LibJS: Convert internal_define_own_property() to ThrowCompletionOr 2021-09-29 23:49:53 +01:00
Linus Groh
0e69a6e487 LibJS: Convert internal_get_own_property() to ThrowCompletionOr 2021-09-29 23:49:53 +01:00
Linus Groh
8f3a5ba5d8 LibJS: Add Array::create_from() for generic Vector<T>
It relies on a mapper function to convert each T& to a JS::Value. This
allows us to avoid awkward Vector<T> to MarkedValueList conversion at
the call site.
2021-09-04 19:08:18 +01:00
Idan Horowitz
c351b4ad0d LibJS: Stop using a native property for Array lengths
Specifically, replace it with a specification-based implementation that
overrides the internal methods that interact with the length property
instead.
2021-07-07 10:14:44 +01:00
Linus Groh
0ba81dc0b7 LibJS: Remove Object::is_array() in favor of Value::is_array() and RTTI
It's way too easy to get this wrong: for the IsArray abstract operation,
Value::is_array() needs to be called. Since we have RTTI, the virtual
Object::is_array() method is not needed anymore - if we need to know
whether something is *actually* a JS::Array (we currently check in more
cases than we should, I think) and not a Proxy with an Array target, we
should do that in a way that doesn't look like an abstract operation.
2021-07-06 14:26:18 +01:00
Linus Groh
09bd5f8772 LibJS: Rewrite most of Object for spec compliance :^)
This is a huge patch, I know. In hindsight this perhaps could've been
done slightly more incremental, but I started and then fixed everything
until it worked, and here we are. I tried splitting of some completely
unrelated changes into separate commits, however. Anyway.

This is a rewrite of most of Object, and by extension large parts of
Array, Proxy, Reflect, String, TypedArray, and some other things.

What we already had worked fine for about 90% of things, but getting the
last 10% right proved to be increasingly difficult with the current code
that sort of grew organically and is only very loosely based on the
spec - this became especially obvious when we started fixing a large
number of test262 failures.

Key changes include:

- 1:1 matching function names and parameters of all object-related
  functions, to avoid ambiguity. Previously we had things like put(),
  which the spec doesn't have - as a result it wasn't always clear which
  need to be used.
- Better separation between object abstract operations and internal
  methods - the former are always the same, the latter can be overridden
  (and are therefore virtual). The internal methods (i.e. [[Foo]] in the
  spec) are now prefixed with 'internal_' for clarity - again, it was
  previously not always clear which AO a certain method represents,
  get() could've been both Get and [[Get]] (I don't know which one it
  was closer to right now).
  Note that some of the old names have been kept until all code relying
  on them is updated, but they are now simple wrappers around the
  closest matching standard abstract operation.
- Simplifications of the storage layer: functions that write values to
  storage are now prefixed with 'storage_' to make their purpose clear,
  and as they are not part of the spec they should not contain any steps
  specified by it. Much functionality is now covered by the layers above
  it and was removed (e.g. handling of accessors, attribute checks).
- PropertyAttributes has been greatly simplified, and is being replaced
  by PropertyDescriptor - a concept similar to the current
  implementation, but more aligned with the actual spec. See the commit
  message of the previous commit where it was introduced for details.
- As a bonus, and since I had to look at the spec a whole lot anyway, I
  introduced more inline comments with the exact steps from the spec -
  this makes it super easy to verify correctness.
- East-const all the things.

As a result of all of this, things are much more correct but a bit
slower now. Retaining speed wasn't a consideration at all, I have done
no profiling of the new code - there might be low hanging fruits, which
we can then harvest separately.

Special thanks to Idan for helping me with this by tracking down bugs,
updating everything outside of LibJS to work with these changes (LibWeb,
Spreadsheet, HackStudio), as well as providing countless patches to fix
regressions I introduced - there still are very few (we got it down to
5), but we also get many new passing test262 tests in return. :^)

Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 22:07:36 +01:00
Idan Horowitz
e480d69130 LibJS: Bring ArrayCreate and ArrayConstructor closer to spec
Specifically, this now explicitly takes the length, adds missing
exceptions checks to calls with user-supplied lengths, takes and uses
the prototype argument, and fixes some spec non-conformance in
ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 00:51:43 +01:00
Linus Groh
1c906b07a4 LibJS: Add length parameter to Array::create()
This is now a bit closer to the spec's 10.4.2.2 ArrayCreate - it will
throw a RangeError if the requested length exceeds 2^32 - 1, so anyone
passing in a custom value (defaults to zero for same behaviour as
before) will need an exception check at the call site.
2021-06-06 23:25:33 +01:00
Brian Gianforcaro
1682f0b760 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 11:22:27 +02:00
Linus Groh
1c3eef5317 LibJS: Use MarkedValueList for internal own properties getter functions
Letting these create and return a JS::Array directly is pretty awkward
since we then need to go through the indexed properties for iteration.
Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new
Array::create_from() function to turn the Vector into a returnable
Array as we did before.

This brings it a lot closer to the spec as well, which uses the
CreateArrayFromList abstract operation to do exactly this.

There's an optimization opportunity for the future here, since we know
the Vector's size we could prepare the newly created Array accordingly,
e.g. by switching to generic storage upfront if needed.
2021-04-07 09:05:01 +02:00
Linus Groh
a72276407b LibJS: Make ArrayPrototype an Array object
https://tc39.es/ecma262/#sec-properties-of-the-array-prototype-object

The Array prototype object: [...] is an Array exotic object and has the
internal methods specified for such objects.

NOTE: The Array prototype object is specified to be an Array exotic
object to ensure compatibility with ECMAScript code that was created
prior to the ECMAScript 2015 specification.
2021-02-24 10:22:17 +01:00
Andreas Kling
13d7c09125 Libraries: Move to Userland/Libraries/ 2021-01-12 12:17:46 +01:00
Renamed from Libraries/LibJS/Runtime/Array.h (Browse further)