summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Runtime/JSONObject.cpp
AgeCommit message (Collapse)Author
2021-07-06LibJS: Add define_direct_property and remove the define_property helperIdan Horowitz
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-06LibJS: Add missing exception check in internalize_json_propertyLuke
The call to enumerable_own_property_names in the non-array case was missing an exception check. Fixes 1 test262 case (JSON/parse/reviver-object-own-keys-err.js)
2021-07-05LibJS: Remove unnecessary value_or() from get()Linus Groh
Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04LibJS: Rewrite most of Object for spec compliance :^)Linus Groh
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-04LibJS: Bring ArrayCreate and ArrayConstructor closer to specIdan Horowitz
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-01LibJS: Bring JSON.parse slightly closer to the specificationIdan Horowitz
This PR does not fix the main issue with our current implementation: The specification requires that we first check the JSON string for validity with an ECMA-404 compliant parser, and then evaluate it as if it was javascript code, of which we do neither at the moment.
2021-07-01LibJS: Bring JSON.stringify closer to the specificationIdan Horowitz
2021-06-27LibJS: Rename Function => FunctionObjectAndreas Kling
2021-06-25LibJS: Change PropertyName(Symbol*) => PropertyName(Symbol&)Linus Groh
Requires a bunch of find-and-replace updates across LibJS, but constructing a PropertyName from a nullptr Symbol* should not be possible - let's enforce this at the compiler level instead of using VERIFY() (and already dereference Symbol pointers at the call site).
2021-06-20LibJS: Introduce AbstractOperations.{cpp,h} and move various AOs thereLinus Groh
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-16LibJS: Replace Object's create_empty() with create() taking a prototypeLinus Groh
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-13LibJS: Add ECMA-262 section/title/URL comments almost everywhereLinus Groh
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-08LibJS: Handle Proxy with Array target in IsArray() abstract operationLinus Groh
This was missing from Value::is_array(), which is equivalent to the spec's IsArray() abstract operation - it treats a Proxy value with an Array target object as being an Array. It can throw, so needs both the global object and an exception check now.
2021-04-23Userland: Use mattco@serenityos.org for my copyright headersMatthew Olsson
2021-04-22Everything: Move to SPDX license identifiers in all files.Brian Gianforcaro
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-16LibJS: Dont try to serialize symbol-keyed propertiesIdan Horowitz
As per the specification: "All Symbol-keyed properties will be completely ignored, even when using the replacer function."
2021-04-16LibJS: Remove #if !defined(KERNEL)Linus Groh
AK::JsonValue::{is,as}_double() is not available in the kernel, but that doesn't affect LibJS.
2021-02-23Everywhere: Rename ASSERT => VERIFYAndreas Kling
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-04LibJS: Fix obviously wrong \uXXXX serialization in JSONObjectAndreas Kling
2021-01-12Libraries: Move to Userland/Libraries/Andreas Kling