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
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
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
This patch provides functions to extract the fragment directive from a url / a hash
into an array of `TextDirective`s
as well as to create a fragment directive string from given text directives.
The algorithms are implemented as a rust crate.
Interface functions and data structures which are accessible from C++
are provided in `lib.rs`.
The actual implementation (using pure rust types)
lives in `fragment_directive_impl.rs`, tests live in `test.rs`.
The implementation currently only supports text directives.
Other future directive types are not considered and will be ignored.
The main function, `parse_fragment_directive()` takes a url / a url hash
as parameter and returns (as out parameter) a struct which contains the stripped input url,
the fragment directive string, and an array of parsed text directive objects.
Additionally, there are functions that create a full fragment directive string
from a list of text directives as well as a function that creates
a single text directive string from a text directive.
The `TextDirective` class, which is shared with C++, contains four
string elements for the prefix, start, end and suffix elements.
These strings are percent-decoded and do not contain identifiers
(like the `-` that indicates it being a prefix or suffix).
All elements besides `start` can be empty.
The implemented algorithms are used in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D195685
This patch provides functions to extract the fragment directive from a url / a hash
into an array of `TextDirective`s
as well as to create a fragment directive string from given text directives.
The algorithms are implemented as a rust crate.
Interface functions and data structures which are accessible from C++
are provided in `lib.rs`.
The actual implementation (using pure rust types)
lives in `fragment_directive_impl.rs`, tests live in `test.rs`.
The implementation currently only supports text directives.
Other future directive types are not considered and will be ignored.
The main function, `parse_fragment_directive()` takes a url / a url hash
as parameter and returns (as out parameter) a struct which contains the stripped input url,
the fragment directive string, and an array of parsed text directive objects.
Additionally, there are functions that create a full fragment directive string
from a list of text directives as well as a function that creates
a single text directive string from a text directive.
The `TextDirective` class, which is shared with C++, contains four
string elements for the prefix, start, end and suffix elements.
These strings are percent-decoded and do not contain identifiers
(like the `-` that indicates it being a prefix or suffix).
All elements besides `start` can be empty.
The implemented algorithms are used in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D195685
This patch provides functions to extract the fragment directive from a url / a hash
into an array of `TextDirective`s
as well as to create a fragment directive string from given text directives.
The algorithms are implemented as a rust crate.
Interface functions and data structures which are accessible from C++
are provided in `lib.rs`.
The actual implementation (using pure rust types)
lives in `fragment_directive_impl.rs`, tests live in `test.rs`.
The implementation currently only supports text directives.
Other future directive types are not considered and will be ignored.
The main function, `parse_fragment_directive()` takes a url / a url hash
as parameter and returns (as out parameter) a struct which contains the stripped input url,
the fragment directive string, and an array of parsed text directive objects.
Additionally, there are functions that create a full fragment directive string
from a list of text directives as well as a function that creates
a single text directive string from a text directive.
The `TextDirective` class, which is shared with C++, contains four
string elements for the prefix, start, end and suffix elements.
These strings are percent-decoded and do not contain identifiers
(like the `-` that indicates it being a prefix or suffix).
All elements besides `start` can be empty.
The implemented algorithms are used in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D195685
This patch provides functions to extract the fragment directive from a url / a hash
into an array of `TextDirective`s
as well as to create a fragment directive string from given text directives.
The algorithms are implemented as a rust crate.
Interface functions and data structures which are accessible from C++
are provided in `lib.rs`.
The actual implementation (using pure rust types)
lives in `fragment_directive_impl.rs`, tests live in `test.rs`.
The implementation currently only supports text directives.
Other future directive types are not considered and will be ignored.
The main function, `parse_fragment_directive()` takes a url / a url hash
as parameter and returns (as out parameter) a struct which contains the stripped input url,
the fragment directive string, and an array of parsed text directive objects.
Additionally, there are functions that create a full fragment directive string
from a list of text directives as well as a function that creates
a single text directive string from a text directive.
The `TextDirective` class, which is shared with C++, contains four
string elements for the prefix, start, end and suffix elements.
These strings are percent-decoded and do not contain identifiers
(like the `-` that indicates it being a prefix or suffix).
All elements besides `start` can be empty.
The implemented algorithms are used in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D195685
This is part 1 of 3 and vendors the [suggest component](https://github.com/mozilla/application-services/tree/main/components/suggest) from
application-services into m-c. `suggest` depends on `remote_settings`, so it was
also vendored. Part 2 will generate JS bindings with uniffi.
This is my first time doing this so I'll explain how I generated this patch in
case I did something wrong:
1. I manually added `suggest` to the following files:
* Top-level `Cargo.toml`
* `toolkit/library/rust/shared/Cargo.toml`
* `toolkit/library/rust/shared/lib.rs` -- I followed the example of `tabs`,
not sure if `suggest::uniffi_reexport_scaffolding!()` is necessary
2. I ran `./mach vendor rust`
That's it, there were no errors or problems.
Differential Revision: https://phabricator.services.mozilla.com/D187323
This crate contains the required bits to store annotations in a process and
let the mozannotation_server crate find them and pull them out. Functionally
there's not much happening here as all the actual functionality is in
mozannotation_server.
Differential Revision: https://phabricator.services.mozilla.com/D173697
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
