Commit graph

27 commits

Author SHA1 Message Date
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
581f20e6f2 LibJS: Accept FlyStrings in the NativeFunction constructors
This makes the implicit run-time assertion in PropertyName::to_string()
into an explicit compile-time requirement, removes a wasteful FlyString
-> PropertyName -> FlyString construction from NativeFunction::create()
and allows setting the function name to a null string for anonymous
native functions.
2021-06-28 08:55:14 +01:00
Andreas Kling
ba9d5c4d54 LibJS: Rename Function => FunctionObject 2021-06-27 22:36:04 +02:00
Linus Groh
8a06a93ce2 LibJS: Return non-object argument unaltered from Object.setPrototypeOf()
This was missing step 3 from the spec:

    3. If Type(O) is not Object, return O.

Also use RequireObjectCoercible() for a better error message and make
the rest of the code a bit easier to read and more similar to the spec
text.
2021-06-22 18:59:24 +01:00
Linus Groh
8f6ac0db1c LibJS: Use OrdinaryCreateFromConstructor() in a bunch of constructors
Resolves various FIXMEs :^)
2021-06-20 12:12:39 +02:00
Linus Groh
55db9539a5 LibJS: Introduce AbstractOperations.{cpp,h} and move various AOs there
Value.{cpp,h} has become a dumping ground, let's change that.

Things that are directly related to Values (e.g. bitwise/binary ops,
equality related functions) can remain, but everything else that's not a
Value or Object method and globally required (not just a static function
somewhere) is being moved.

Also convert to east-const while we're here.

I haven't touched IteratorOperations.{cpp,h}, it seems fine to still
have those separately.
2021-06-20 12:12:39 +02:00
Linus Groh
317b88a8c3 LibJS: Replace Object's create_empty() with create() taking a prototype
This now matches the spec's OrdinaryObjectCreate() across the board:
instead of implicitly setting the created object's prototype to
%Object.prototype% and then in many cases setting it to a nullptr right
away, it now has an 'Object* prototype' parameter with _no default
value_. This makes the code easier to compare with the spec, very clear
in terms of what prototype is being used as well as avoiding unnecessary
shape transitions.

Also fixes a couple of cases were we weren't setting the correct
prototype.

There's no reason to assume that the object would not be empty (as in
having own properties), so let's follow our existing pattern of
Type::create(...) and simply call it 'create'.
2021-06-16 22:49:04 +01:00
Idan Horowitz
9a0cbcc3d1 LibJS: Add the Object.fromEntries method 2021-06-15 12:15:18 +01:00
Linus Groh
7327a28ccc 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:33:28 +01:00
Idan Horowitz
bd9e20ef79 LibJS: Add the Object.getOwnPropertySymbols method 2021-06-12 18:39:23 +01:00
Idan Horowitz
a2da3f97ef LibJS: Remove argument count checks in Object.* methods
These are inconsistent with the specification.
2021-06-12 18:39:23 +01:00
Linus Groh
7e1bffdeb8 LibJS: Implement Object.assign() 2021-06-12 11:36:17 +01:00
Idan Horowitz
f9395efaac LibJS: Use ToPropertyKey in Object.getOwnPropertyDescriptor
The specification requires this. (And the current usage of
PropertyName::from_value is invalid since integers are not allowed in
this context)
2021-06-07 16:51:09 +01:00
Idan Horowitz
eb0b1c432a LibJS: Replace StringOrSymbol::from_value with Value::to_property_key
This is a more specification compliant implementation of the
abstract operation 7.1.19 ToPropertyKey which should handle boxed
symbols correctly.
2021-06-05 14:15:28 +01:00
Andreas Kling
3ee092cd0c LibJS: Implement Object.hasOwn() :^)
This is currently a TC39 Stage 2 proposal, but let's go for it!

https://github.com/tc39/proposal-accessible-object-hasownproperty

I wrote the C++, @linusg found bugs and wrote the test.
2021-05-18 11:18:19 +02:00
Linus Groh
c61de8e4be LibJS: Use Object::get_own_properties() for getOwnPropertyNames() 2021-04-25 22:40:21 +02:00
Linus Groh
ebdeed087c Everywhere: Use linusg@serenityos.org for my copyright headers 2021-04-22 22:51:19 +02: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
9cd010167a LibJS: Implement Object.create() 2021-04-10 21:00:04 +02:00
Linus Groh
da8a35a79e LibJS: Implement Object.defineProperties() 2021-04-10 21:00:04 +02:00
Linus Groh
f3264b0dbd LibJS: Implement Object.isFrozen() and Object.isSealed() 2021-04-07 09:05:01 +02:00
Linus Groh
9af07c7803 LibJS: Implement Object.freeze() and Object.seal() 2021-04-07 09:05:01 +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
1416027486 LibJS: Add Object::get_enumerable_own_property_names() and use it
Object::get_own_properties() is a bit unwieldy to use - especially as
StringOnly is about to no longer be the default value. The spec has an
abstract operation specifically for this (EnumerateObjectProperties),
so let's use that. No functionality change.
2021-04-05 19:30:30 +02:00
Linus Groh
afc86abe24 LibJS: Remove this_object parameter from get/put own property functions
Specifically:

- Object::get_own_properties()
- Object::put_own_property()
- Object::put_own_property_by_index()

These APIs make no sense (and are inconsistent, get_own_property()
didn't have this parameter, for example) - and as expected we were
always passing in the same object we were calling the method on anyway.
2021-04-05 19:30:30 +02:00
Andreas Kling
635a5eec75 LibJS: Remove a whole bunch of unnecessary #includes 2021-02-10 09:13:29 +01:00
Andreas Kling
13d7c09125 Libraries: Move to Userland/Libraries/ 2021-01-12 12:17:46 +01:00
Renamed from Libraries/LibJS/Runtime/ObjectConstructor.cpp (Browse further)