The bytecode interpreter can execute generator functions while the AST
interpreter cannot. This simply makes it create a new bytecode
interpreter when one doesn't exist when executing a generator function.
Doing so makes it automatically switch to the bytecode interpreter to
execute any future code until it exits the generator.
The lack of this action caused a bug in my original patch
(https://github.com/SerenityOS/serenity/pull/16004) that appeared when
accessing a site that redirected the client and it was the first site
the client loaded.
This utility essentially creates a filesystem sandbox for a specified
command, so it can be tested with only the unveiled paths the user
specifies beforehand.
This could be used in a scenario when it is expected that a user program
will be invoked with a specific option multiple times, for example:
"program --a-option=example --a-option=anotherexample ..."
To accomplish this, we add another VeilState which is called
LockedInherited. The idea is to apply exec unveil data, similar to
execpromises of the pledge syscall, on the current exec'ed program
during the execve sequence. When applying the forced unveil data, the
veil state is set to be locked but the special state of LockedInherited
ensures that if the new program tries to unveil paths, the request will
silently be ignored, so the program will continue running without
receiving an error, but is still can only use the paths that were
unveiled before the exec syscall. This in turn, allows us to use the
unveil syscall with a special utility to sandbox other userland programs
in terms of what is visible to them on the filesystem, and is usable on
both programs that use or don't use the unveil syscall in their code.
Disregarding minimum widget size was originally set as a quick fix
when converting Assistant to a Popup window, but it's really much
easier to let layout manage dynamic resizing instead of trying to
add up pixels piecemeal.
This gives search results a more tactile look and feel, consistent
with other iconified widgets across the system. Custom provider
subtitles now appear as tooltips.
This patch adds the `USING_AK_GLOBALLY` macro which is enabled by
default, but can be overridden by build flags.
This is a step towards integrating Jakt and AK types.
Previously, throw and return completions would not be executed inside
the generator. This is incorrect, as throw and return need to perform
unwinds which can potentially execute more code inside the generator,
such as finally blocks.
This is done by also passing the completion type alongside the passed
in value. The continuation block will immediately extract and type and
value and perform the appropriate operation for the given type.
For normal completions, this is continuing as normal.
For throw completions, it will perform `throw <value>`.
For return completions, it will perform `return <value>`, which is a
`Yield return` in this case due to being inside a generator.
This also refactors GeneratorObject to properly send across the
completion type and value to the generator inside of trying to operate
on the completions itself.
This is a prerequisite for yield*, as it performs special iterator
operations when receiving a throw/return completion and does not
complete the generator like the regular yield would.
There's still more work to be done to make GeneratorObject::execute
be closer to the spec. It's mostly a restructuring of the existing
GeneratorObject::next_impl.
Unwind contexts need to be preserved as we exit and re-enter a
generator.
For example, this would previously crash when returning from the try
statement after yielding as we lost the unwind context when yielding,
but still have a LeaveUnwindContext instruction from running
`perform_needed_unwinds` when generating the return statement.
```js
function* a() {
try {
return (yield 1);
} catch {}
}
iter = a();
iter.next();
iter.next();
```
Most of the 64-bit instructions default to 32-bit operands and select
64-bit using REX.W prefixes. Because of that instead of defining new
instruction formats, this reuses the 32-bit formats and changes them
to take the REX prefixes into account when necessary.
Additionally this removes, adds or modifies the instruction
descriptors in the 64-bit table, where they are different from 32-bit.
Using 'disasm' these changes seem to cover pretty much all of our
64-bit binaries (except for AVX) :^)
Note that UserspaceEmulator will need to account for these prefixed
versions in its 32-bit instruction handlers before being usable on
x86-64.
Instead of assuming the virtual offset will be 8 hex digits (which is OK
for 32 bit values), just use the ":p" modifier to ensure it prints the
virtual offset as a pointer, so if the code is compiled for 64 bit CPUs,
it will use 16 hex digits accordingly.
Previously, hexdump used Core::File to read input into a fixed buffer.
This PR rewrites the file handling to use the more modern
Core::Stream::File, which reads data into spans. By using spans, we
can also simplify the rest of the code, which previously used memcpy
for array manipulation and relied on manual bookkeeping to keep track of
offsets.
We now replace the current history entry if the page-load has been
caused because of a redirect. This makes it able to traverse the
history if one of the entries redirects you, which previously
caused an infinite history traversion loop.
Previously we labeled redirects as normal FrameLoader::Type::Navigation,
now we introduce a new FrameLoader::Type::Redirect and label redirects
with it. This will allow us to handle redirects in the browser
differently (such as for overwritting the latest history entry when a
redirect happens) :^)
The main menu in GUI (the one in the lower left side of screen by
default) was called start_menu in some parts of the code and system_menu
in others. In the documentation, it was referred to as "system menu".
So, in order to be consistent, these variables are all renamed to
system_menu
The Core::System::create_jail function already provided the new jail
index as a result, so it was just a matter of using it when calling the
LibCore join_jail function to use the new jail.
This *also* got missed in the gcc-12 update, because we weren't
installing an explicit gcc version prior. Hopefully that's the last of
the long tail of issues from that migration!
Many of these functions will treat the 'pointer' parameter as an offset
into a buffer if one is currently bound.
This makes it possible to run ClassiCube with OpenGL 1.5 support!
For performance, it is desirable to defer evaluation of intrinsics that
are stored on the GlobalObject for every created Realm. To support this,
Object now maintains a global storage map to store lambdas that will
return the associated intrinsic when evaluated. Once accessed, the
instrinsic is moved from this global map to normal Object storage.
To prevent this flow from becoming observable, when a deferred intrinsic
is stored, we still place an empty object in the normal Object storage.
This is so we still create the metadata for the object, and in doing so,
can preserve insertion order of the Object storage. Otherwise, this will
be observable by way of Object.getOwnPropertyDescriptors.
This changes Intrinsics to not initialize most of its constructors and
prototype right away. We still initialize a few that are needed before
some others are created, though we may eventually be able to "link"
dependencies at compile time to avoid this.
After splitting a node, the new node was written to the same pointer as
the current node - probably a copy / paste error. This new code requires
a `.pointer() -> u32` to exist on the object to be serialized,
preventing this issue from happening again.
Fixes#15844.
