This replaces the C++ GenerateWindowOrWorkerInterfaces generator with a
python3 port.
The generator uses the new python WebIDL parser and writes directly to a
TextIO instance instead of porting SourceGenerator.
For validation, the python generator was diffed against the existing C++
generator over the full LibWeb IDL input set. The generated output is
behaviorally identical, and the only changes are whitespace changes
(all improvements).
Generate exact JS buffer types for exact IDL buffer arguments instead
of widening them to BufferSource or ArrayBufferView.
This fixes cases like TextEncoder.encodeInto(), whose IDL requires
a Uint8Array destination. Previously the generated binding accepted
any BufferSource, so DataView, other typed arrays, and
ArrayBuffer-backed values were let through. With exact conversion,
those are rejected at the binding layer as expected.
We don't match the C++ output byte-for-byte here, because the key
iteration order is different. So I've taken the opportunity to tidy up
some whitespace too.
Move partial interface, partial namespace, mixin, typedef, and overload
finalization into a context-wide post-parse resolve step.
This lets BindingsGenerator parse all declared IDL files first and then
finalize the shared IDL context before generating bindings.
Teach the bindings build to pass support IDL files alongside the regular
binding IDLs so BindingsGenerator parses the full declared IDL set into
a shared context.
Keep idl_files.cmake as the source of truth for parsed support IDLs, and
let Interface::will_generate_code() decide which parsed interfaces emit
generated bindings.
Stop using imported modules to decide which binding headers to include.
Instead, collect dependencies from referenced interfaces, dictionaries,
enumerations, callbacks, and nested IDL types in the parsed context.
Derive C++ namespaces from each IDL module's location and use those
qualified names when generating binding code.
Also Teach dictionaries their owning IDL module path so dictionary C++
types can be qualified the same way as interfaces. This removes the need
for the generated `using namespace Web::*` hack and the hard-coded
namespace list.
Also fix DOMURL.idl to refer to the IDL interface name `URL`, not the
C++ implementation name `DOMURL`.
No other third layer folder in LibWeb has its own namespace which
makes this a special case for the IDLGenerator when determining
namespaces. Instead of adding a special case, simply remove the
namespace.
Teach BindingsGenerator to parse and generate bindings for the full
LibWeb IDL set in one invocation, and collapse the CMake bindings
rules from one custom command per IDL file to a single batched codegen
step.
This has the downsides of:
* Any single IDL change now reruns the whole bindings generator
* Per-IDL parallelism at the custom-command level is lost
However, I still feel that this is a worthy trade off as:
* Generated files are written with write_if_changed(), so rebuilds
of generated files should not be significantly impacted.
* It is not a common task to be modifying IDL files
* Most importantly, giving the IDL generator full knowledge of _all_
IDL will allow for some simplifications of the bindings generator as
it has knowledge of all types.
Use the shared IDL context when checking whether a type is a JSON type
instead of walking imported modules from the current interface. This
removes another dependency on explicit #import directives when resolving
interface inheritance for toJSON.
When creating an inheritance stack, look up parent interfaces from the
parsed IDL context instead of the current interface's imported modules.
This removes a dependency on explicit #import directives during bindings
generation.
Import WebIDL/Function.idl where TimerHandler uses Function, and let the
bindings generator handle it through the normal callback-function path.
This removes the special C++ mapping for Function and makes TimerHandler
use GC::Root<CallbackType>, matching the generated binding type when IDL
files are parsed together.
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.
This allows us to avoid the ugly hack in
`property_accepted_type_ranges()`.
This also updates the `ValueType` to be `opacity-value` rather than
`opacity` to match the spec.
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.
Remove the special case assignment path for string dictionary members.
The old logic was using the outer dictionary conversion’s optional and
optional_default_value state to decide how to assign an individual
member, which was very confusing and not correct.
This was probably needed on earlier buggier versions of the IDL
generator working around the wrong problem.
Which would be required if we added, for example, IDL which had
the missing types as part of a sequence. Also arange them in
terms of size while we are here.
