...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.
This requires a special case with names as the default function is
supposed to have a unique name ("*default*" in our case) but when
checked should have name "default".
Before this we attempted to hack around this by only overriding
has_binding. However this did not cover all cases, for example when
assigning to variables before their declaration it didn't throw.
By using the new find_binding_and_index virtual method we can just
pretend the indirect bindings are real.
Since indirect binding do come from a normal environment we need to
ensure you cannot modify the binding and that properties like mutable
are false as expected by the spec for such an indirect binding.
This is an export which looks like `export {} from "module"`, and
although it doesn't have any real export entries it should still add
"module" to the required modules to load.