Split the generator decision for shared prototype and constructor
objects. Interfaces with custom prototype behavior can still use the
shared InterfaceConstructor when the constructor object itself has no
custom GC cell state.
Teach Intrinsics how to register a shared constructor for an existing
custom prototype object, and keep LegacyFactoryFunction aliases wired up
when the primary interface objects are shared.
Many generated Web IDL prototype and constructor objects have no
per-interface storage and no custom virtual behavior. They only differ
by metadata such as their exposed name, parent interface, constructor
hook, and generated initialization functions.
Add shared InterfacePrototypeObject and InterfaceConstructor classes for
these simple interfaces. The generators now emit per-interface metadata
and static helper functions instead of distinct GC::Cell subclasses when
the interface does not need special object behavior.
This avoids creating separate type-isolated GC allocators for hundreds
of otherwise empty prototype and constructor classes, while preserving
constructors, unforgeable attributes, IDL conversions, and immutable
prototypes in the global prototype chain.
Generate per-type bindings helpers for converting JS values to IDL
dictionary and enum values.
This makes the generated API line up better with the spec's
"converted to an IDL value" wording and gives us some functions to
use for future cleanup of manual IDL conversion code.
Split include dependency collection into source header and generated
bindings header paths to prepare for dictionary and enum conversion
being split from being generated where they are used by an interface.
Previously we were inconsistent by generating code for enum definitions
but not generating code for dictionaries. With future changes to the
IDL generator to expose helpers to convert to and from IDL values
this produced circular depdendencies. To solve this problem, also
generate the dictionary definitions in bindings headers.
Change the bindings generator to emit enum definitions into the
Bindings/<Thing>.h file owned by the IDL that defines them, including
support IDLs that do not have a top-level interface or namespace.
Allow enum-only modules to generate bindings headers and make generated
bindings code include those owner headers when another IDL depends on
their enums.
This allows us to replace the hand made NavigationType.h header with
one generated by bindings.
Teach LibWeb codegen to emit a generated bindings header and
implementation for every IDL in the CMake inputs, including support only
IDLs.
For IDLs that do not yet produce bindings content, keep generation going
through IDLGenerators and emit empty placeholder files. This prepares
per-IDL generated definitions without changing the overall generation
flow.
Make idl_type_name_to_cpp_type() return the same base C++ type for
nullable and non-nullable IDL types. Nullability is handled by the
surrounding codegen logic, and this helper does not have enough
context to decide storage/wrapping semantics on its own.
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.
