If the stored symbol is custom (non-global), it is allocated on the
heap, and may not be visited by anyone else, so we must register it in
order to keep it alive.
This was previously indirectly forcing Heap/Handle.h to include it
instead. This will let us include Handle.h from PropertyKey, which will
allow us to solve a different issue.
This still needs a project-wide cleanup to remove handles captured in
lambdas, which is now longer required.
For now, this will be used in the next commit implementing promise AOs
from Web IDL, which make heavy use of deferred callbacks.
SafeFunction automatically registers its closure memory area in a place
where the JS garbage collector can find it.
This means that you can capture JS::Value and arbitrary pointers into
the GC heap in closures, as long as you're using a SafeFunction, and the
GC will not zap those values!
There's probably some performance impact from this, and there's a lot of
things that could be nicer/smarter about it, but let's build something
that ensures safety first, and we can worry about performance later. :^)
...and the other Console methods.
This lets you apply styling to a log message or any other text that
passes through the Console `Formatter` operation.
We store the CSS on the ConsoleClient instead of passing it along with
the rest of the message, since I couldn't figure out a nice way of
doing that, as Formatter has to return JS::Values. This way isn't nice,
and has a risk of forgetting to clear the style and having it apply to
subsequent messages, but it works.
This is only supported in the Browser for now. REPL support would
require parsing the CSS and figuring out the relevant ANSI codes. We
also don't filter this styling at all, so you can `position: absolute`
and `transform: translate(...)` all you want, which is less than
ideal.
JS::Value stores 48 bit pointers to separately allocated objects in its
payload. On x86-64, canonical addresses have their top 16 bits set to
the same value as bit 47, effectively meaning that the value has to be
sign-extended to get the pointer. AArch64, however, expects the topmost
bits to be all zeros.
This commit gates sign extension behind `#if ARCH(X86_64)`, and adds an
`#error` for unsupported architectures, so that we do not forget to
think about pointer handling when porting to a new architecture.
Fixes#15290FixesSerenityOS/ladybird#56
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibJS/Runtime/StringPrototype.h>
// That's it, this was enough to cause a compilation error.
Likewise for most other files touched by this commit.
In a subclass of Cell, we cannot use Cell::vm() before the base Cell
object itself is constructed. Use the Realm's VM instead.
This was caught by UBSAN with vptr sanitation enabled.
IsArray returns true if the object is an Array *or* if it is a
ProxyObject whose target is an Array. Therefore, we cannot downcast to
an Array based on IsArray.
Luckily, we don't actually need an Array here; SerializeJSONArray only
needs an Object.
This was caught by UBSAN with vptr sanitation enabled.
Instead of calling Core::EventLoop directly, LibJS now has a virtual
function on VM::CustomData for customizing this behavior.
We use this in LibWeb to plumb the spin request through to the
PlatformEventPlugin.
This allows JS::Script to mark its corresponding HTML::Script, even if
it's a little roundabout looking. Fixes an issue where the JS::Script
was kept alive by the execution stack, but the HTML::Script was gone.
This was originally part of 8f9ed415a0
but got lost in a merging accident.
This allows the garbage collector to keep HTML::Script objects alive and
fixes a bug where a HTMLScriptElement could get GC'd while its code was
executing.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
This is generated by GenerateLocaleData, which will soon be in the
Locale namespace. Move it out of CurrencyCode.h, as that will continue
to live in the Unicode namespace.
These are two new smart pointers that are really just raw pointers under
the hood. The initial benefit is all in the names, they allow us to
declare that we're pointing at something in the GC heap.
Later we may also find ways to add debugging logic or static analysis to
these types.
