- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
Some crates in our graph have dependencies on parking_lot >= 0.11,
<=0.12, meaning `cargo update` might pull parking_lot 0.12, which brings
windows-sys.
mio >= 0.8.1 also pulls windows-sys in.
Differential Revision: https://phabricator.services.mozilla.com/D148587
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062