summaryrefslogtreecommitdiff
path: root/Userland/Applications/Spreadsheet/JSIntegration.h
AgeCommit message (Collapse)Author
2023-01-29LibJS+Everywhere: Allow Cell::initialize overrides to throw OOM errorsTimothy Flynn
Note that as of this commit, there aren't any such throwers, and the call site in Heap::allocate will drop exceptions on the floor. This commit only serves to change the declaration of the overrides, make sure they return an empty value, and to propagate OOM errors frm their base initialize invocations.
2022-12-06AK+Everywhere: Rename String to DeprecatedStringLinus Groh
We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-08-28LibJS: Turn initialize_global_object() into a regular initialize()Linus Groh
There's nothing special about global object initialization anymore, this can just work the same way as for any other object now.
2022-08-23LibJS: Pass Realm to GlobalObject::initialize_global_object()Linus Groh
Global object initialization is tightly coupled to realm creation, so simply pass it to the function instead of relying on the non-standard 'associated realm' concept, which I'd like to remove later. This works essentially the same way as regular Object::initialize() now. Additionally this allows us to forward the realm to GlobalObject's add_constructor() / initialize_constructor() helpers, so they set the correct realm on the allocated constructor function object.
2022-08-23LibJS+LibWeb: Replace GlobalObject with Realm in initialize() functionsLinus Groh
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-23LibJS+LibWeb: Replace GlobalObject with Realm in object constructorsLinus Groh
No functional changes - we can still very easily get to the global object via `Realm::global_object()`. This is in preparation of moving the intrinsics to the realm and no longer having to pass a global object when allocating any object. In a few (now, and many more in subsequent commits) places we get a realm using `GlobalObject::associated_realm()`, this is intended to be temporary. For example, create() functions will later receive the same treatment and are passed a realm instead of a global object.
2022-08-05LibJS: Let Shape store a Realm instead of a GlobalObjectAndreas Kling
This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-06-26Spreadsheet: Make it possible to refer to ranges in other sheetsAli Mohammad Pur
Now the range A0:C4 in a sheet named "foo" can be represented as: R`sheet("foo"):A0:C4` This makes it possible to do cross-sheet lookups and more.
2022-02-14Applications: Use default constructors/destructorsLenny Maiorani
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-01-22LibJS: Refactor interpreter to use Script and Source Text ModulesLuke Wilde
This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2021-12-12Spreadsheet: Reimplement ranges as lazy objects instead of arraysAli Mohammad Pur
Doing so makes it possible to talk about theoretically infinite ranges like "all of column A".
2021-10-31Spreadsheet: Convert JSIntegration to ThrowCompletionOrTimothy Flynn
2021-10-24LibJS: Rename PropertyName to PropertyKeyAndreas Kling
Let's use the same name as the spec. :^)
2021-10-20LibJS: Add ThrowCompletionOr versions of the JS native function macrosIdan Horowitz
The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all native functions were converted to the new format.
2021-09-30SpreadSheet: Fix that the js integration abused global objectsdavidot
Before this commit it only allocated the global object so when it wanted to lookup 'thisSheet' it could not find it in the global environment. We now hotswap the global object everytime a cell evaluated. This also fixes that SheetGlobalObject did not have an internal_has_property meaning 'A0' could not be referenced unless it was via a member lookup (this.A0). This was already broken before the bindings refactoring. The correct behavior of realms in spreadsheet is not completely clear since what is shared between sheets is not very well defined. The reason that just setting the SheetGlobalObject as the global_this_value is not enough is because ECMAScript does not check the global_this_value for members when resolving a reference in the global environment.
2021-09-29LibJS: Convert internal_set() to ThrowCompletionOrLinus Groh
2021-09-29LibJS: Convert internal_get() to ThrowCompletionOrLinus Groh
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-06-17LibJS: Replace boolean without_side_effects parameters with an enumIdan Horowitz
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-12LibJS: Make Errors fully spec compliantLinus Groh
The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-03-17LibJS: Rename GlobalObject::initialize() => initialize_global_object()Andreas Kling
This function was shadowing Object::initialize() which cannot be called on global objects and has a different set of parameters.
2021-01-12Applications: Move to Userland/Applications/Andreas Kling