This has two advantages: First the picker no longer changes the active
window state of its parent. Visually this is an additional hint that the
dialog is "fragile" and will close on loss of focus. Second, because
it contains a search box, its own input won't be preempted by global
application shortcuts when typing (pending #15129). This is a problem
in apps like PixelPaint which use shortcuts without modifiers.
Currently, LibUnicodeData contains the generated UCD and CLDR data. Move
the UCD data to the main LibUnicode library, and rename LibUnicodeData
to LibLocaleData. This is another prepatory change to migrate to
LibLocale.
And adjust some GML properties. Since a808cfa, splitters grow
opportunistically. Setting them to fixed sizes now quite literally
fixes them in place. Fixes immovable splitters missed in the
aforementioned commit.
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
with the CaptureInput WindowMode. This mode will serve the same
function as accessories: redirecting input while allowing parent
windows to remain active.
The basic idea is that a global object cannot just come out of nowhere,
it must be associated to a realm - so get it from there, if needed.
This is to enforce the changes from all the previous commits by not
handing out global objects unless you actually have an initialized
realm (either stored somewhere, or the VM's current realm).
- Prefer VM::current_realm() over GlobalObject::associated_realm()
- Prefer VM::heap() over GlobalObject::heap()
- Prefer Cell::vm() over Cell::global_object()
- Prefer Wrapper::vm() over Wrapper::global_object()
- Inline Realm::global_object() calls used to access intrinsics as they
will later perform a direct lookup without going through the global
object
This is needed so that the allocated NativeFunction receives the correct
realm, usually forwarded from the Object's initialize() function, rather
than using the current realm.
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.
This is a continuation of the previous six commits.
The global object is only needed to return it if the execution context
stack is empty, but that doesn't seem like a useful thing to allow in
the first place - if you're not currently executing JS, and the
execution context stack is empty, there is no this value to retrieve.
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
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.
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.
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.
Using the fact that there are 2^52-2 NaN representations we can
"NaN-box" all the Values possible. This means that Value no longer has
an explicit "Type" but that information is now stored in the bits of a
double. This is done by "tagging" the top two bytes of the double.
For a full explanation see the large comment with asserts at the top of
Value.
We can also use the exact representation of the tags to make checking
properties like nullish, or is_cell quicker. But the largest gains are
in the fact that the size of a Value is now halved.
The SunSpider and other benchmarks have been ran to confirm that there
are no regressions in performance compared to the previous
implementation. The tests never performed worse and in some cases
performed better. But the biggest differences can be seen in memory
usage when large arrays are allocated. A simple test which allocates a
1000 arrays of size 100000 has roughly half the memory usage.
There is also space in the representations for future expansions such as
tuples and records.
To ensure that Values on the stack and registers are not lost during
garbage collection we also have to add a check to the Heap to check for
any of the cell tags and extracting the canonical form of the pointer
if it matches.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
For some reason LibGUI sends two events for each edit, and one of them
contains an OOB cursor if a character was deleted.
This works around that for now.
This is a bit of a hack, but it is an easy way to finally get spacers
into GML.
This will translate well if spacers are later to become child objects of
the continer widget.
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
Instead of having the undo operation only be able to undo one cell
for a given undo, make it able to handle multiple cells at a time.
Please enter the commit message for your changes. Lines starting
Previously, the paste action was always enabled and always assumed that
anything was selected, which led to a crash by clicking the paste action
right after the application startup.
This patch will automatically enable/disable the paste action depending
on whether a selection exists (it usually does, except on the app launch
and after adding a new tab) and if the clipboard mime type is a text/
group.
So no, you can't paste an image into the app anymore, even though this
mostly froze the app before...
Forgot to remove that in c0c9825f67, as
this function was no longer declared and used... Until the previous
commit.
This meant that pressing the F2 key after opening a file no longer
matched the current tab.
Besides from reusing more parts from the code, this allows us to call
the action using the F2 key. That is also the reason why we have
to reassign `m_tab_context_menu_sheet_view` on tab change.
This is useful, for instance, in games in which you can switch held
items using the scroll wheel. In order to implement this, they
previously would have to either add a hard-coded division by 4, or look
up your mouse settings to adjust correctly.
This commit adds an MouseEvent.wheel_raw_delta_x() and
MouseEvent.wheel_raw_delta_y().
These can be generated by saving something that's not serialisable (e.g.
functions), skip over them and let the load logic reevaluate them when
needed.
Take into account the current scroll position when calculating the
position of cells. This way when the user scrolls either horizontally
or vertically, the calculations done to find the cell position
will be correct.
When the drop location of a drag-and-drop operation is not valid, then
don't continue with the drop_event. For example, if the ending location
is the header row or header column, or is outside of the table, then
should not continue.
Implements ability to extend a cell's contents by clicking the bottom
right of the cell and dragging in a linear direction. For now, the
content that is extended is simply a copy of the target cell's
values.
Since copying and cutting uses the cell values in the origin to decide
which values to paste in the destination, it is necessary to do it
in an ordered manner when the origin and destination ranges overlap.
Otherwise you may overwrite values in the origin unintentionally
before having successfully transferred them to the destination.
Use cut instead of copy when dragging one or many cells' contents.
This is more intuitive as most other spreadsheet applications
handle the drag in this manner instead of as a copy operation.
When finished dragging and cutting, select the cells in the
destination. E.g. if you select 5 cells and drag and paste
them in a new location, select the 5 pasted cells in the
destination.
Due to the fact that in the AbstractView, when multiple cells are
selected, and then another cell is selected within this selection,
the cursor is not updated as the user may be beginning to drag, have
to override this functionality for the Spreadsheet application.
This is because in spreadsheets when multiple cells are selected,
and then you click on one of the cells within the selection,
the selection should be cleared and the targetted cell highlighted.
Due to the margin that is given to be able to select cells for
cutting or extending, have to override the mouse click function
so that the targetted cell is chosen and not the one that may be
beneath the cursor.
Depending on the cursor location with respect to a selected cell,
display different icons pertaining to the distinct possible actions,
for example dragging and cutting, extending the cell's contents, or
doing a simple selection.
It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
Previously, we were setting tab actions only for the active tab on a tab
change, and the same actions for the previous tab were removed.
Unfortunately, this also happened when making a new tab, which meant
that you could trick the cell editor to jump to the new sheet and start
writing there.
To fix this, every view will always have on_selection_changed
and on_selection_dropped assigned. I haven't seen much difference in
the memory usage, so I guess it'll be fine :)
NumericCell::display() attempted to take a substring of cell contents
according to the "Override max length" parameter,
but it did not account for the actual string length.
The previous code never executed, as SpreadsheetView splits selection
events into `on_selection_changed` and `on_selection_dropped` depending
on whether there is any selection.
Prior to this commit, there was a set_filename() function that could set
the window title, but actually it never did that. It was called only
in one place -- by the 'Save as...' action, but it always failed to
change anything, because there was a check that tried to reassign
the same filename. :/
This patch:
1. removes that check, and therefore
2. renames the function to simply `update_window_title()`,
3. starts calling the function from more places (at startup and after
loading a file),
4. changes the window title order
(`{app_name} - {filename}` -> `{filename} - {app_name}`) to match
the other applications style on the system. :^)
Up until now, the Spreadsheet function examples appeared below their
descriptions. Let's swap them to make it clearer which JS example
goes to which description.
The Spreadsheet application currently does not support undo/redo,
and with this update, we are starting the process of adding this feature
:-)
Additionally, the save dialog has been updated to use
GUI::MessageBox::ask_about_unsaved_changes() for system cohesity.
Spreadsheet: Add basic undo functinoality
The spreadsheet application now has basic support for undo. Testing of
this feature is limited, and may not work as intended yet.
Spreadsheet: Add callback when a cell's value is changed
In addition to the callback being added, this commit also exposes the
SheetModel class via a getter in SpreadSheetView.
Spreadsheet: Remove debug statements and use cell change callback
This commit uses the on_cell_data_change callback from within the
SheetModel class. This allows for us to push/pop changes to the undo
stack.
With this, we have basic Undo/Redo functionality :-)
Spreadsheet: Actually add window::set_modified
Spreadsheet: Const-correctness :-)
Spreadsheet: Reorder the edit menu actions
Now that the GML formatter is both perserving comments and also mostly
agrees to the existing GML style, it can be used to auto-format all the
GML files in the system. This commit does not only contain the scripts
for running the formatting on CI and the pre-commit hook, but also
initially formats all the existing GML files so that the hook is
successfull.
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.
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
No previous model index will be invalidated afterwards, so avoid
invalidating them.
Also fixes an issue where committing to an edit with the inline cell
editor makes the focused cell switch to A0.
Fixes#9677.
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
Earlier, we were using 0 value for characters not found in "map".
We should return failure for invalid inputs.
So, I have changed the return type of function to Optional<size_t>.
Also changed caller to handle Optional return.
Fixed convert_from_string() function to return correct output.
The value of a number is equal to sum of each digit multiplied by it's
positional weight.
Most of the models were just calling did_update anyway, which is
pointless since it can be unified to the base Model class. Instead, code
calling update() will now call invalidate(), which functions identically
and is more obvious in what it does.
Additionally, a default implementation is provided, which removes the
need to add empty implementations of update() for each model subclass.
Co-Authored-By: Ali Mohammad Pur <ali.mpfard@gmail.com>
Applications previously had to create a GUI::Menubar object, add menus
to it, and then call GUI::Window::set_menubar().
This patch introduces GUI::Window::add_menu() which creates the menubar
automatically and adds items to it. Application code becomes slightly
simpler as a result. :^)
File Manager and Spreadsheet had an inconsistent order relative
to other apps (they had a copy-cut-paste order, where every other app
had a cut-copy-paste order).
In the Spreadsheet app, selecting a cell and typing something (like
"1") would create an empty editing delegate, set "1" as its value and
immediately select the entire contents of the text box. If your goal
was to type "123", that "1" was selected and will be replaced by "23".
This changes the behavior of TableView to not select the editing
delegate's contents if its creation was a result of a keydown event.
The actual data file for this benchmark was never actually committed to
the repository, so let's generate 100k identical lines in memory to be
the fairly large data for this test instead.
This removes all usages of the non-standard put helper method and
replaces all of it's usages with the specification required alternative
or with define_direct_property where appropriate.
These are usually incorrect, and people sometimes forget to add the
correct values as a result of them being optional, so they should just
be specified explicitly.
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>
This removes StringView::find_first_of(char) and find_last_of(char) and
replaces all its usages with find and find_last respectively. This is
because those two methods are functionally equivalent.
find_{first,last}_of should only be used if searching for multiple
different characters, which is never the case with the char argument.
This also adds the [[nodiscard]] to the remaining find_{first,last}_of
methods.
The LexicalPath instance methods dirname(), basename(), title() and
extension() will be changed to return StringView const& in a further
commit. Due to this, users creating temporary LexicalPath objects just
to call one of those getters will recieve a StringView const& pointing
to a possible freed buffer.
To avoid this, static methods for those APIs have been added, which will
return a String by value to avoid those problems. All cases where
temporary LexicalPath objects have been used as described above haven
been changed to use the static APIs.
This removes JsonObject::get_or(), which is inefficient because it has
to copy the returned value. It was only used in a few cases, some of
which resulted in copying JsonObjects, which can become quite large.
This changes JsonObject to use the new OrderedHashMap instead of an
extra vector for tracking the insertion order.
This also adds a default value for the KeyTraits template argument in
OrderedHashMap. Furthermore, it fixes two cases where code iterating
over a JsonObject relied on the value argument being copied before
invoking the callback.
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'.
