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
Currently, for each exposed interface, we generate one massive function
to create every Web constructor and prototype. In an effort to lazily
create these instead, this first step is to extract the creation of each
of these into its own method.
First, this generates a forwarding header for all IDL types. This is to
allow callers to remain unchanged without forcing them to include the
(very heavy) generated IDL headers. This header is included by LibWeb's
forwarding header.
Next, this defines a base template method on Web::Bindings::Intrinsics
to create a prototype/constructor pair. Specializations of this template
are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base
Intrinsics class is updated to use this new method, and will continue to
cache the result.
Last, some WebAssembly classes are updated to use this new mechanism.
They were using some ad hoc cache keys that are now in line with the
generated specializations.
That one massive function is still used to invoke these specializations,
so they are not lazy as of this commit.
This commit teaches BindingsGenerator to generate depfiles, which can be
used by CMake to ensure that bindings are properly regenerated when
imported IDL files change.
Two new options, `--depfile` and `--depfile-target` are added.
- `--depfile` sets the path for the dependency file.
- `--depfile-target` lets us set a target name different than the output
file in the depfile. This option is needed because generated files are
first written to a temporary file, but depfiles have to refer to the
final location.
These are analogous to GCC's `-MF` and `-MT` options respectively. The
depfile's syntax matches the ones generated by GCC.
Note: This changes the minimal required CMake version to 3.20 if the
Make generator is used, and to 3.21 for the Xcode generator. Ninja is
not affected.
We have logic for serenity_generated_sources which works well for source
files that are specified in GENERATED_SOURCES prior to calling
serenity_lib or serenity_bin. However, code generated with
invoke_generator, and the LibWeb generators do not always follow the
pattern of the IDL and GML files.
For the LibWeb generators, we can just add_dependencies to LibWeb at the
time we declare the generate_Foo custom target. However for LibLocale,
LibTimeZone, and LibUnicode, we don't have the name of the target
available, so export the name in a variable to set into
GENERATED_SOURCES.
To make this work for Lagom, we need to make sure that lagom_lib and
serenity_bin in Lagom/CMakeLists.txt call serenity_generated_sources on
the target.
This enables the Xcode generator on macOS hosts, at least for Lagom.
Also do this for Shell.
This greatly simplifies the CMakeLists in Lagom, replacing many glob
patterns with a big list of libraries. There are still a few special
libraries that need some help to conform to the pattern, like LibELF and
LibWebView.
It also lets us remove essentially all of the Serenity or Lagom binary
directory detection logic from code generators, as now both projects
directories enter the generator logic from the same place.
This new code generator takes all the .idl files in LibWeb, looks for
each top level interface in there with an [Exposed=Foo] attribute, and
adds code to add the constructor and prototype for each of those exposed
interfaces to the realm of the relevant global object we're initialzing.
It will soon replace WindowObjectHelper as the way that web interfaces
are added to the Window object, and will be used in the future for
creating proper WorkerGlobalScope objects for dedicated and shared
workers.
This code generator no longer creates JS wrappers for platform objects
in the old sense, instead they're JS objects internally themselves.
Most of what we generate now are prototypes - which can be seen as
bindings for the internal C++ methods implementing getters, setters, and
methods - as well as object constructors, i.e. bindings for the internal
create_with_global_object() method.
Also tweak the naming of various CMake glue code existing around this.
To enable incremental movement towards the removal of DOM object
instance wrappers, this patch adds a NO_INSTANCE argument that can be
passed to libweb_js_wrapper().
