We currently support optional integral types, but not nullable types. So
if an IDL contains e.g. "long?", passing null will be coerced to 0.
This will be used by the Inspector, but will also eventually be used by
real IDL interfaces (e.g. HTMLInputElement's selectionStart).
This can apply to optional, nullable parameters of platform types. This
will cause the generator to generate the type as
Optional<JS::GCPtr<T>> rather than JS::GCPtr<T>, allowing the
implementation to differentiate between the case where the argument was
not passed, and the case where null or undefined was passed.
Needing to differentiate these two cases is quite niche, hence why it is
an opt-in behavior.
We have two known PlatformObjects that need to implement some of the
behavior of LegacyPlatformObjects to date: Window, and HTMLFormElement.
To make this not require double (or virtual) inheritance of
PlatformObject, move the behavior of LegacyPlatformObject into
PlatformObject. The selection of LegacyPlatformObject behavior is done
with a new bitfield of feature flags instead of a dozen virtual
functions that return bool. This change simplifies every class involved
in the diff with the notable exception of Window, which now needs some
ugly const casts to implement named property access.
We would previously always generate string parameters to pass through
to functions as a `String`. This works fine if the argument is a
`FlyString const&`, but falls apart for optional types where we need to
accept an `Optional<FlyString> const&`.
Support this by implementing a [FlyString] extended attribute which
if present results in the parameter for the function being generated
as a FlyString.
This is how the spec tells us we should be converting to these integer
types.
Also leave around a FIXME to pass through information about the [Clamp]
and [EnforceRange] extended attributes, and port over these instances to
the new WebIDL integer typedefs.
Per:
https://dom.spec.whatwg.org/#concept-reflect
We should be calling `get_attribute_value` for reflected IDL strings.
No functional change as nowhere is performing a reflect on a nullable
type, and just ends up simplifying the code.
In a bunch of cases, this actually ends up simplifying the code as
to_number will handle something such as:
```
Optional<I> opt;
if constexpr (IsSigned<I>)
opt = view.to_int<I>();
else
opt = view.to_uint<I>();
```
For us.
The main goal here however is to have a single generic number conversion
API between all of the String classes.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
These wrappers will make it much easier to do various operations on the
different ArrayBuffer-related classes in LibWeb compared to the current
solution, which is to just accept a Handle<Object> everywhere (and use
"any" in the *.idl files).
Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
Aside from the obvious performance benefits, this will allow us to
properly handle dictionary types. (whose dictionary-ness is only known
at build-time)
Much of the rest of the overload resolution algorithm steps can (and
should) be evaluated at build-time as well, but this is a good first
step.
When wrapping dictionary members, generate_wrap_statement was called
with the pattern "auto {} = ...", where "..." was determined based on
the variable's type. However, in generate_wrap_statement, if a type is
nullable it generates an if statement, so this would end up generating
something along the lines of
if (!retval.member.has_value()) {
auto wrapped_member0_value = JS::js_null();
} else {
auto wrapped_member0_value = JS::Value(...);
}
...which makes the declaration inaccessible. It now generates the same
code, but the "auto" declaration (now an explicit JS::Value declaration)
is outside of the if-statement.
That API came from a mistake in the IDL compiler, where reflected
nullable attributes would try to call set_attribute(name, null).
This commit fixes the mistake in the IDL generator, and removes the
meaningless API.
This commit removes DeprecatedString's "null" state, and replaces all
its users with one of the following:
- A normal, empty DeprecatedString
- Optional<DeprecatedString>
Note that null states of DeprecatedFlyString/StringView/etc are *not*
affected by this commit. However, DeprecatedString::empty() is now
considered equal to a null StringView.
These functions all have a very common case that can be dealt with a
very simple inline check, often avoiding the need to call an out-of-line
function. This patch moves the common case to inline functions in a new
ValueInlines.h header (necessary due to header dependency issues..)
8% speed-up on the entire Kraken benchmark :^)
This function must return true if the object may intercept and customize
access to indexed properties (properties where the property name is a
non-negative integer.)
This will be used to implement fast path optimizations for array-like
accesses in subsequent commits.
