We already have "global" as a way to access the global object in js(1)
(both REPL and script mode). This replaces it with "globalThis", which
is available in all environments, not just js.
This patch adds a new kind of JS::Value, the empty value.
It's what you get when you do JSValue() (or most commonly, {} in C++.)
An empty Value signifies the absence of a value, and should never be
visible to JavaScript itself. As of right now, it's used for array
holes and as a return value when an exception has been thrown and we
just want to unwind.
This patch is a bit of a mess as I had to fix a whole bunch of code
that was relying on JSValue() being undefined, etc.
Objects can have both named and indexed properties. Previously we kept
all property names as strings. This patch separates named and indexed
properties and splits them between Object::m_storage and m_elements.
This allows us to do much faster array-style access using numeric
indices. It also makes the Array class much less special, since all
Objects now have number-indexed storage. :^)
Introduce a central assert implementation so that the LibJS test suite
can take advantage of one implementation instead of copy/pasting the
same function into every test case file.
This patch adds a way for a socket to ask to be routed through a
specific interface.
Currently, this option only applies to sending, however, it should also
apply to receiving...somehow :^)
Only return whatever a "return" statment told us to return.
The last computed value is now available in Interpreter::last_value()
instead, where the REPL can pick it up.
StartDownload requests for unhandled protocols (or invalid URLs) will
now refuse to load instead of asserting. A failure code is sent back
to LibProtocol and Protocol::Client::start_download() returns nullptr.
Fixes#1604.
This allows us to construct menus in a more natural way:
auto& file_menu = menubar->add_menu("File");
file_menu.add_action(...);
Instead of the old way:
auto file_menu = GUI::Menu::construct();
file_menu->add_action(...);
menubar->add_menu(file_menu);
Calling save("file") in a repl saves all the typed lines so far
into the specified file. It currently does not have great support for
multilined functions since those get turned into one line.
This patch adds JS::Shape, which implements a transition tree for our
Object class. Object property keys, prototypes and attributes are now
stored in a Shape, and each Object has a Shape.
When adding a property to an Object, we make a transition from the old
Shape to a new Shape. If we've made the same exact transition in the
past (with another Object), we reuse the same transition and both
objects may now share a Shape.
This will become the foundation of inline caching and other engine
optimizations in the future. :^)
We now print thrown exceptions and clear the interpreter state so it
can continue running instead of refusing to do anything after an
exception has been thrown.
Fixes#1572.
Let's move towards using references over pointers in LibJS as well.
I had originally steered away from it because that's how I've seen
things done in other engines. But this is not the other engines. :^)
When we enter a repl we call initialize_global_object on our custom
ReplObject in order to expose REPL specific features. Specifically:
help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
LibWeb now creates a WindowObject which inherits from GlobalObject.
Allocation of the global object is moved out of the Interpreter ctor
to allow for specialized construction.
The existing Window interfaces are moved to WindowObject with their
implementation code in the new Window class.
This adds:
- A global Date object (with `length` property and `now` function)
- The Date constructor (no arguments yet)
- The Date prototype (with `get*` functions)
With this patch, it's now possible to pass a Gfx::ShareableBitmap in an
IPC message. As long as the message itself is synchronous, the bitmap
will be adopted by the receiving end, and disowned by the sender nicely
without any accounting effort like we've had to do in the past.
Use this in NotificationServer to allow sending arbitrary bitmaps as
icons instead of paths-to-icons.
We currently use icon paths for this because I didn't want to deal with
implementing icon bitmap sharing right now. In the future it would be
better to post a bitmap somehow instead of a path.
