When an IDL file has #imports and the IDL interface exposes an iterator,
the bindings generator would generate #include statements missing the
class name of the iterator in the form 'LibWeb/{namespace}/Iterator'.
This change only generates the iterator #include statement for the top
interface that is the iterator.
These are treated differently as the interface members are placed on the
object itself, not its prototype.
As the object itself still needs to be hand-written code, and we can no
longer fully hide the gnarly generated code in the prototype object,
these now generate a 'mixin' class that is added to the actual object
through inheritance.
https://webidl.spec.whatwg.org/#Global
The Window object is massive, so let's do the conversion to IDL step
by step. First up: getting rid of the manual constructor and prototype
definitions, which can be generated from an empty `interface Window`.
This relied on pulling the current realm from the main thread VM, which
requires an execution context to be on the VM's stack. This heavily
relied on the dummy execution context that is always on the stack, for
example, when parsing the UA style sheets where no JavaScript is
running.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
This also removes DirIterator::error_string(), since the same strerror()
string will be included when you print the Error itself. Except in `ls`
which is still using fprintf() for now.
This sorts the array of generated emoji data by code point (first by
code point length, then by code point value). This lets us use a binary
search to find emoji data, rather than the current linear search.
In a profile of scrolling around /home/anon/Documents/emoji.txt, this
reduces the runtime of Gfx::Emoji::emoji_for_code_points from 69.03% to
28.42%. Within that, Unicode::find_emoji_for_code_points reduces from
28.42% to just 1.95%.
Similar to the FontDatabase, this will be needed for Ladybird to find
emoji images. We now generate just the file name of emoji image in
LibUnicode, and look for that file in the specified path (defaulting to
/res/emoji) at runtime.
`consume_until(foo)` stops before foo, and so does
`ignore_until(Predicate)`, so let's make the other `ignore_until()`
overloads consistent with that so they're less confusing.
This commit moves the implementation of getopt into AK, and converts its
API to understand and use StringView instead of char*.
Everything else is caught in the crossfire of making
Option::accept_value() take a StringView instead of a char const*.
With this, we must now pass a Span<StringView> to ArgsParser::parse(),
applications using LibMain are unaffected, but anything not using that
or taking its own argc/argv has to construct a Vector<StringView> for
this method.
This adds the condition member.type->is_string() to the if statement, so
that we now conditionally check the dictionary member is a new string
and associated with an optional constructor parameter.
When a constructor has an optional dictionary as argument, and those
members are of type new string, make sure that we release_value()
setting the dictionary members.
This makes use of the new [UseNewAKString] extended attribute. Using
Vector storage will make it easier to make this interface into an IDL
iterable. It seems the reason it didn't use Vector originally was due
to awkward DeprecatedString -> String conversions.
Adding the [UseNewAKString] extended attribute to an interface will
cause all IDL string types to use String instead of DeprecatedString.
This is done on an per interface level instead of per type/parameter
because:
- It's much simpler to implement, as the generators can already access
the interface's extended attributes. Doing it per type/parameter
would mean parsing and piping extended attributes for each type that
doesn't already take extended attributes, such as unions.
- Allows more incremental adoption of AK::String. For example, adding
[UseNewAKString] to BodyInit would require refactoring Request,
Response and XMLHttpRequest to AK::String in one swoop. Doing it on
the interface allows you to convert just XHR and its dependencies at
once, for example.
- Simple string return types (i.e. not parameterised or not in a union)
already accept any of the string types JS::PrimitiveString::create
accepts. For example, you can add [UseNewAKString] to DOMStringMap to
convert Element attributes to AK::String and still return AK::String
from get_attribute, without adding [UseNewAKString] to Element.
- Adding [UseNewAKString] to one function typically means adding it to
a bunch of other functions, if not the rest of them. For example,
adding [UseNewAKString] to the parameters FormData.append would
either mean converting AK::String to AK::DeprecatedString or storing
the AK::String as-is, making the other functions of FormData have to
convert back from AK::String or also support AK::String.
This includes an Error::create overload to create an Error from a UTF-8
StringView. If creating a String from that view fails, the factory will
return an OOM InternalError instead. VM::throw_completion can also make
use of this overload via its perfect forwarding.
For example, consider cases where we want to propagate errors only in
specific instances:
auto result = read_data(); // something like ErrorOr<ByteBuffer>
if (result.is_error() && result.error().code() != EINTR)
continue;
auto bytes = TRY(result);
The TRY invocation will currently copy the byte buffer when the
expression (in this case, just a local variable) is stored into
_temporary_result.
This patch binds the expression to a reference to prevent such copies.
In less trival invocations (such as TRY(some_function()), this will
incur only temporary lifetime extensions, i.e. no functional change.
First, this adds an overload of PrimitiveString::create for StringView.
This overload will throw an OOM completion if creating a String fails.
This is not only a bit more convenient, but it also ensures at compile
time that all PrimitiveString::create(string_view) invocations will be
handled as String and OOM-aware.
Next, this wraps all invocations to PrimitiveString::create(string_view)
with MUST_OR_THROW_OOM.
A small PrimitiveString::create(DeprecatedFlyString) overload also had
to be added to disambiguate between the StringView and DeprecatedString
overloads.
