Updated uniffi-bindgen-gecko-js to work with UniFFI 0.25.2:
- Use `config.toml` to list UniFFI sources. This makes it easier to
associate data with them, for example the `crate_name` field that's
now required to generate the sources.
- Enable the `extern-rustbuffer` feature on `uniffi_core`
- Updated the external types fixture to work around
https://github.com/mozilla/uniffi-rs/issues/1872
Ran mach vendor and mach cargo vet to update the Rust crates.
Differential Revision: https://phabricator.services.mozilla.com/D195163
This commit vendors the latest changes to the Suggest and Remote
Settings Rust components.
1. From the `application-services` source tree, I ran
`./tools/update-moz-central-vendoring.py ../m-c` to update the
revisions in the m-c source tree.
2. I added the Remote Settings component UDL file to
`toolkit/components/uniffi-bindgen-gecko-js/mach_commands.py`, and
updated `toolkit/components/uniffi-bindgen-gecko-js/config.toml` to
call the `RemoteSettings` constructor on the main thread. The
Suggest component uses the `RemoteSettingsConfig` type in its
public API, so we must generate bindings for the Remote Settings
component.
3. From the m-c source tree, I ran `./mach uniffi generate` to update
the generated UniFFI bindings.
Differential Revision: https://phabricator.services.mozilla.com/D187559
This is part 2 of 3 and generates JS bindings for the `suggest` component. Part 1
is D187323.
This is my first time doing this so I'll explain how I generated this patch in
case I did something wrong:
1. Added `suggest` to `toolkit/components/uniffi-bindgen-gecko-js/mach_commands.py`
2. Added `[suggest.receiver_thread]` to `toolkit/components/uniffi-bindgen-gecko-js/config.toml` so the `SuggestStore` ctor and `interrupt()` method are main-thread
3. Ran `./mach uniffi generate`
4. Added the generated `RustSuggest.sys.mjs` to `mc/toolkit/components/uniffi-bindgen-gecko-js/components/moz.build`
Depends on D187323
Differential Revision: https://phabricator.services.mozilla.com/D187324
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
- Implemented `checkType` on more UniFFI FFIConverters.
- Updated the way we handle locating the errors.
- The old system was that `checkType` inputted a `name` parameter. I
think the idea was that parent types would calculate a name
parameter for their children. However, this wasn't great because
it meant we would need to build the strings up-front and throw
them away in the vast majority of cases where there was no type
error.
- The new system is that we use the `UniFFITypeError` class, which
has a `prependPath` method. This gets called by the parent type
FFIConverter to basically do the same work, but it only needs to
happen when there's actually an error.
- I think the resulting error messages are pretty good. I got this
when passing a list with garbage data to setLocalTabs: "TypeError:
remoteTabs[0].title: undefined is not a string"
- Added the `UniFFI.sys.mjs` module, which contains shared, non-generated,
UniFFI JS code. This is prep-work for
https://bugzilla.mozilla.org/show_bug.cgi?id=1804078.
Differential Revision: https://phabricator.services.mozilla.com/D166479
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
This is a repsonse to the build errors I noticed with
build-macosx64-hybrid/plain, build-win64-hybrid/plain, and
build-linux64-hybrid/plain.
I'm not exactly sure why those build had errors but others didn't, but
my guess is that it was a combination of:
- A clang++ producing different warnings/errors.
- The uniffied builds being arranged slightly differently, which
surfaced errors based on missing include statements.
Differential Revision: https://phabricator.services.mozilla.com/D153414
To test the bindings generation, we generate JS bindings for a set of test
Rust crates, then run xpcshell tests against those bindings.
Currently these tests only run when the `--enable-uniffi-fixtures`
option is set, so they need to be run manually be a dev. I'd love to
create a system where these can optionally run in CI, but I'm not sure
how to do that.
Differential Revision: https://phabricator.services.mozilla.com/D144469
Added `mach uniffi generate` which executes `uniffi-bindgen-gecko-js` to
generate UniFFI bindings. It's unfortunate that we need to check these
files in, but I couldn't figure out a way to auto-generate them as part
of the build process.
Adding `#include "nsIContent.h"` to dom/base/nsINodeList.h. I think
that should have been present before, but things built okay because of
the way things got combined in the uniffied .cpp files. Adding these new
webIDL files bumped `NodeListBinding.cpp` to a new uniffied .cpp file
which caused the build to fail.
Differential Revision: https://phabricator.services.mozilla.com/D144468
- 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
This is a repsonse to the build errors I noticed with
build-macosx64-hybrid/plain, build-win64-hybrid/plain, and
build-linux64-hybrid/plain.
I'm not exactly sure why those build had errors but others didn't, but
my guess is that it was a combination of:
- A clang++ producing different warnings/errors.
- The uniffied builds being arranged slightly differently, which
surfaced errors based on missing include statements.
Differential Revision: https://phabricator.services.mozilla.com/D153414
To test the bindings generation, we generate JS bindings for a set of test
Rust crates, then run xpcshell tests against those bindings.
Currently these tests only run when the `--enable-uniffi-fixtures`
option is set, so they need to be run manually be a dev. I'd love to
create a system where these can optionally run in CI, but I'm not sure
how to do that.
Differential Revision: https://phabricator.services.mozilla.com/D144469
Noemi Erli
Ben Dean-Kawamura
Joel Maher
Tif Tran
Drew Willcoxon
Lina Butler
Mark Hammond
Jan-Erik Rediger
Sandor Molnar
Mike Hommey
Iulian Moraru
Mark Banner
Mathew Hodson
Ryan VanderMeulen
Csoregi Natalia
Sylvestre Ledru
Sammy Khamis
pmcmanis
Butkovits Atila
Andi-Bogdan Postelnicu