Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
This has some risks as it can (attempt to) load arbitrary files on the
filesystem but for now it can only load local files which do go through
normal file operations. But let's enable it for now to see what we can
do with it.
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>
The point of a reference type is to behave just like the referred-to
type. So, a Foo& should behave just like a Foo.
In these cases, we had a const Vector. If it was a const Vector of Foo,
iterating over the Vector would only permit taking const references to
the individual Foos.
However, we had a const Vector of Foo&. The behavior should not
change. We should still only be permitted to take const references to
the individual Foos. Otherwise, we would be allowed to mutate the
individual Foos, which would mutate the elements of the const Vector.
This wouldn't modify the stored pointers, but it would modify the
objects that the references refer to. Since references should be
transparent, this should not be legal.
So it should be impossible to get mutable references into a const
Vector. Since we need mutable references in these cases to call the
mutating member functions, we need to mark the Vector as mutable as
well.
Change the parent of the WizardDialog to that of the Spreadsheet window.
Previously the WizardDialog was using the open file dialog as the
parent resulting in the csv import dialog
Instead of making it a void function, checking for an exception, and
then receiving the relevant result via VM::last_value(), we can
consolidate all of this by using completions.
This allows us to remove more uses of VM::exception(), and all uses of
VM::last_value().
In the end this is a nicer API than having separate has_{value,target}()
and having to check those first, and then making another Optional from
the unwrapped value:
completion.has_value() ? completion.value() : Optional<Value> {}
// ^^^^^^^^^^^^^^^^^^
// Implicit creation of non-empty Optional<Value>
This way we need to unwrap the optional ourselves, but can easily pass
it to something else as well.
This is in anticipation of the AST using completions :^)
When selecting a cell in the spreadsheet that was added
automatically as per the InfinitelyScrollableTableView
implementation, the background color is now filled correctly.
Previously, when navigating horizontally in a spreadsheet, after
a certain point the cells would not have the same background fill
color as the user would have experienced in the previous column
ranges (A-Z).
This is partially a revert of commits:
10a8b6d411561b67a1ad
Rather than adding the prot_exec pledge requried to use dlopen(), we can
link directly against LibUnicodeData in applications that we know need
that library.
This might make the dlopen() dance a bit unnecessary. The same purpose
might now be fulfilled with weak symbols. That can be revisted next, but
for now, this at least removes the potential security risk of apps like
the Browser having prot_exec privileges.
Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Cell::set_data(String new_data) now checks whether the cell is a
formula-cell and the new_data is an empty string. If this is case, it
will no longer simply return and will now instead actually set the
cell's contents to an empty string.
This fixes an error whereupon committing the string "=" to a cell, it
would not be possible to directly delete the cell's contents. Instead,
it first had to be overwritten with another string, which then could be
deleted.
This could probably be done more elegantly. Right now, I believe,
writing the string "=" to a (formula-)cell already containing an
identical string will result in the cell being marked as dirty, even
though nothing actually changed.
We should use .to_string() and handle the possible exceptions.
This makes the displayed cell contents so much more informative than
'[object Object]' :^)
Now we give each sheet its own interpreter and realm, and only make them
share the VM.
This is to prepare for the next commit, which will be refactoring a
bunch of things to propagate exceptions via ThrowCompletionOr<T>.
The worksheet's realm does not change, and is not shared, so we can
safely leave the global environment be.
This fixes lexical scoping in the spreadsheet's runtime file.
Also add slightly richer parse errors now that we can include a string
literal with returned errors.
This will allow us to use TRY() when working with JSON data.
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.
Previously, all the code to add menus and actions was in main().
This was messy and didn't allow us to reference the actions from
SpreadsheetWidget, which is needed in order to add a toolbar.
This commit moves the menu and action adding code to method on
SpreadsheetWidget called initialize_menubar() which is based upon
applications such as TextEditor which have identically named methods
doing the same thing.
In additon, clipboard_action(), previouly a lambda in main(), has also
been made into a method on SpreadsheetWidget since it would otherwise
be destroyed when it goes out of scope. (This was previously avoided by
declaring the lambda in main() so it's always in scope.)
Because we declare the functions in runtime.js we need the correct
global object to be setup otherwise they cannot be accessed when
switching to the SheetGlobalObject.
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.
