The FFI for this changed upstream. Instead of registering a single
function that inputs a single buffer packed with all arguments, you now
register a function for each method where there is a 1-1 mapping of
arguments. The entire interface is represented by a "vtable" -- AKA a
struct that has a field for each of the method handler functions
To implement the methods, I stole the pattern we were using for regular
calls where we define a base class that's implemented by normal code and
a subclass that's implemented by generated code.
Registering/deregistering callback interfaces is now handled by the
generated code directly. It's simpler this way and now that we don't
have the split between regular and fixture scaffolding, there's not much
need for shared code to handle this.
Kept the decision before to only support "fire-and-forget" callbacks. I
think we will want to revisit this when the we support UniFFI async, but
we can save that for later.
Differential Revision: https://phabricator.services.mozilla.com/D222027
Generate FFI definitions for all FFI types, not just scaffolding
functions. These definitions are not used yet, but this is prep work
for re-enabling callback interface support and adding async support.
Differential Revision: https://phabricator.services.mozilla.com/D222026
I thought we needed to write some code to implement trait interfaces,
but they actually already work. So, let's just add a simple test for
them.
Differential Revision: https://phabricator.services.mozilla.com/D222025
The FFI for this changed upstream. Instead of registering a single
function that inputs a single buffer packed with all arguments, you now
register a function for each method where there is a 1-1 mapping of
arguments. The entire interface is represented by a "vtable" -- AKA a
struct that has a field for each of the method handler functions
To implement the methods, I stole the pattern we were using for regular
calls where we define a base class that's implemented by normal code and
a subclass that's implemented by generated code.
Registering/deregistering callback interfaces is now handled by the
generated code directly. It's simpler this way and now that we don't
have the split between regular and fixture scaffolding, there's not much
need for shared code to handle this.
Kept the decision before to only support "fire-and-forget" callbacks. I
think we will want to revisit this when the we support UniFFI async, but
we can save that for later.
Differential Revision: https://phabricator.services.mozilla.com/D222027
Generate FFI definitions for all FFI types, not just scaffolding
functions. These definitions are not used yet, but this is prep work
for re-enabling callback interface support and adding async support.
Differential Revision: https://phabricator.services.mozilla.com/D222026
I thought we needed to write some code to implement trait interfaces,
but they actually already work. So, let's just add a simple test for
them.
Differential Revision: https://phabricator.services.mozilla.com/D222025
This brought in a breaking change: `Suggestion.icon` is now the `bytes`
type. To accomidate that, added UniFFI support for bytes and updated
the SuggestBackendRust code since that field is now a Uint8Array on the
JS side.
Differential Revision: https://phabricator.services.mozilla.com/D223774
Switched to library mode for generating bindings.
Updated our strategy for UniFFI components/fixtures. There's now a
crate for components and a crate for fixtures. These crates are a
dependency of gkrust-shared and also built as standalone libraries which
UniFFI uses to generate the bindings.
One upshot of this is that we no longer need the `crate_name` or
`udl_file` config values. library-mode can figure out the udl paths
automatically.
Differential Revision: https://phabricator.services.mozilla.com/D221824
Use an intermediate representation for the C++ codegen. This means
converting types from `uniffi::interface` into something that can be
directly rendered in the templates. "Intermediate representation" is
maybe too fancy of a term, but I like the compiler metaphor.
See the bug description for the theory behind this. I like the
difference when seeing it in practice. The template code definitely
gets simpler.
Also, start using the `Component` type, which combines a
`ComponentInterface` and `Config`, rather than always using a tuple.
Differential Revision: https://phabricator.services.mozilla.com/D220634
Use an intermediate representation for the C++ codegen. This means
converting types from `uniffi::interface` into something that can be
directly rendered in the templates. "Intermediate representation" is
maybe too fancy of a term, but I like the compiler metaphor.
See the bug description for the theory behind this. I like the
difference when seeing it in practice. The template code definitely
gets simpler.
Also, start using the `Component` type, which combines a
`ComponentInterface` and `Config`, rather than always using a tuple.
Differential Revision: https://phabricator.services.mozilla.com/D220634
The "js_" or "cpp_" prefixes help clarify the differences between
similar methods. "js_name" is the name of something in the JS code and
"cpp_name" is the name of something in the C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D219686
The C++ templates were hard to understand and modify. Instead of using
the templates, let's monomorphize by hand and generate equivalent
classes for each FFI function signature.
I tried a slightly different approach for the template code. . In the
template struct itself, we now generate some simple Rust structs with
all the data the templates need. I like this because it's easier to
compute these values in Rust than in an Aksama template.
Differential Revision: https://phabricator.services.mozilla.com/D212342
The C++ templates were hard to understand and modify. Instead of using
the templates, let's monomorphize by hand and generate equivalent
classes for each FFI function signature.
I tried a slightly different approach for the template code. . In the
template struct itself, we now generate some simple Rust structs with
all the data the templates need. I like this because it's easier to
compute these values in Rust than in an Aksama template.
Differential Revision: https://phabricator.services.mozilla.com/D212342
The C++ templates were hard to understand and modify. Instead of using
the templates, let's monomorphize by hand and generate equivalent
classes for each FFI function signature.
I tried a slightly different approach for the template code. . In the
template struct itself, we now generate some simple Rust structs with
all the data the templates need. I like this because it's easier to
compute these values in Rust than in an Aksama template.
Differential Revision: https://phabricator.services.mozilla.com/D212342
The C++ templates were hard to understand and modify. Instead of using
the templates, let's monomorphize by hand and generate equivalent
classes for each FFI function signature.
I tried a slightly different approach for the template code. . In the
template struct itself, we now generate some simple Rust structs with
all the data the templates need. I like this because it's easier to
compute these values in Rust than in an Aksama template.
Differential Revision: https://phabricator.services.mozilla.com/D212342
We need to do this now that we're creating FTS tables. I believe this
should fix the vendoring issues. The following tests were failing
before and now are succeeding on my machine:
./mach test browser/components/urlbar/tests/quicksuggest/unit
./mach test browser/components/search/test/browser/telemetry/browser_search_telemetry_sources.js
Differential Revision: https://phabricator.services.mozilla.com/D216598
This version includes the new
`SuggestStoreBuilder#remoteSettingsBucketName()` API.
This commit also makes the chrome JS-exposed `SuggestStoreBuilder`
methods synchronous.
Differential Revision: https://phabricator.services.mozilla.com/D201774
Update:
- UniFFI to 0.27.1
- Glean to 59.0.0
- App-services to a recent version
This removes the need for the goblin build hack, although we still have
duplicate versions of goblin since UniFFI is ahead of the moz-central
version. I think that should be easy to resolve as a follow-up.
Updating uniffi-bindget-gecko-js based on upstream changes:
- Clone objects before lowering them
(https://github.com/mozilla/uniffi-rs/pull/1880)
- Use u64 for the RustBuffer length and capacity field
(https://github.com/mozilla/uniffi-rs/pull/1978)
I didn't implement the new callback interface VTable code. Instead I
simply disabled the one fixture that tests it. I'd rather implement
https://bugzilla.mozilla.org/show_bug.cgi?id=1888668 first, since that
will simplify the process a bunch. The only real-world use-case for
callbacks that I know of is Mark's logging changes, but that will
require implementing trait interfaces anyways so I'd rather wait than
write a bunch of C++ code that we then throw away.
Differential Revision: https://phabricator.services.mozilla.com/D206130
