When resolving a typedef, clone its stored type before applying the
nullability from the use site.
This keeps shared typedef definitions stable when multiple IDL files are
parsed in one generator run.
Change the IDL parser entry point to a static factory returning an
IDL::Module. Modules now own the parsed file identity and import graph,
with an optional reference to the file's real interface when one exists.
This is a step towards running the IDL generator on files without
an interface defined.
Start making IDL::Context represent the shared IDL world used during
code generation.
Move globally visible parsed IDL such as dictionaries, enums,
typedefs, callbacks, mixins, and partial declarations out of individual
Interface objects and into Context.
The main goal of this change is a step towards invoking the IDL
generator on every IDL file at once, rather than per interface.
In the meantime as standalone improvements, this lets code generation
resolve imported IDL types through the shared Context without copying
imported declarations onto each Interface. It also makes duplicate
local declarations unnecessary for imported shared types, since an
interface can reference an enum or dictionary owned by another
parsed IDL module without re-emitting it itself.
Previously, the LibWeb bindings generator would output multiple per
interface files like Prototype/Constructor/Namespace/GlobalMixin
depending on the contents of that IDL file.
This complicates the build system as it means that it does not know
what files will be generated without knowledge of the contents of that
IDL file.
Instead, for each IDL file only generate a single Bindings/<IDLFile>.h
and Bindings/<IDLFile>.cpp.
The proposal has not seemed to progress for a while, and there is
a open issue about module imports which breaks HTML integration.
While we could probably make an AD-HOC change to fix that issue,
it is deep enough in the JS engine that I am not particularly
keen on making that change.
Until other browsers begin to make positive signals about shipping
ShadowRealms, let's remove our implementation for now.
There is still some cleanup that can be done with regard to the
HTML integration, but there are a few more items that need to be
untangled there.
This will allow the IDL generator to query a type name during
code generation and determine whether that type is an interface
or not and use properties of that interface for use in code
generation.
For example, in a future commit, this will be used to determine
whether a given type name is a callback interface.
This adds parsing support for `partial interface mixin` as specified
in WebIDL. Partial mixins are merged into their corresponding mixins
before the mixins are resolved into interfaces.
Previously, an error would occur if an `iterable<T>` was defined before
the required value iterator. An is now also reported if an`iterable<T>`
is defined before a pair iterator, previously this error would only be
reported if the iterable was defined after the pair iterator.
We fill these overload sets from vectors, which means that by the time
we iterated over them, any semblance of their original ordering was
lost. Their ordering is important, because we invoke
define_native_function() for them which eventually stores ordered
properties.
This should not be an issue as long as iterating over a HashMap that was
filled in exactly the same way results in the same ordering. However,
HashTable utilizes kmalloc_good_size() to determine a good allocation
size - and the implementation for kmalloc_good_size() on Linux and macOS
differs, causing a different capacity and ordering on those platforms.
This was not caught by CI, because we run that with sanitizers enabled
which overrides malloc_good_size() on macOS, resulting in the same
behavior as on Linux.
Change the overload sets to be OrderedHashMaps instead and rebaseline
the failing test.
* Remove completely unused methods.
* Deduplicate methods that were overloaded with both StringView and
char const* parameters.
A future commit will templatize GenericLexer by char type. This patch
serves to make that a tiny bit easier.
This adds a new IDL type, Utf16DOMString. This is the same as DOMString,
except it is UTF-16. This type is temporary - we will want DOMString to
be UTF-16 by default once we've ported enough of LibWeb.
To make this support easier, some string IDL generator handling is moved
directly into `generate_to_string` from the call sites.
Partial interfaces have the same name as the interface they extend, and
can appear in any order. In practice, we import the partial interfaces
into the main interface's IDL.
This adds support for async iterators of the form:
async iterable<value_type>;
async iterable<value_type>(/* arguments... */);
It does not yet support the value pairs of the form:
async iterable<key_type, value_type>;
async iterable<key_type, value_type>(/* arguments... */);
Async iterators have an optional `return` data property. There's not a
particularly good way to know what interfaces implement this property.
So this adds a new extended attribute, DefinesAsyncIteratorReturn, which
interfaces can use to declare their support.
There's a bit of a UTF-8 assumption with this change. But nearly every
caller of these methods were immediately creating a String from the
resulting ByteString anyways.
This fixes the frame-ancestors WPT tests from crashing when an iframe
is blocked from loading. This is because it would get an undefined
location.href from the cross-origin iframe, which causes a crash as it
expects it to be there.
In the case, where IDL enums start with a character, that is an invalid
start character for C++ identifiers (e.g. a number), the C++ generaion
for enums fails. An example would be "2d" see #3788
Previously the IDL Parser Complained, that a type with the name ''
(an empty string) couldn't be found. It wasn't that easy to see the
mistake, as the not named type is printed without '' around it, so the
message seemed to miss a type. This now catches this specify error
earlier and reports it cleanly to the user. An example of this
occurring would be ''typedef A (B or //FIXME: C )
This allows us to specify multiple base paths to look for imported IDL
files in. This will allow us to import IDL files from sources and from
the Build directory (i.e. for generated IDL files).
