Update to uniffi v0.24.1 and land Glean & appservices update in m-c
Categories
(Data Platform and Tools :: Glean: SDK, task, P1)
Tracking
(firefox117 fixed)
Tracking | Status | |
---|---|---|
firefox117 | --- | fixed |
People
(Reporter: janerik, Assigned: janerik)
References
Details
Attachments
(5 files)
We need to upgrade uniffi in Glean and land that here in m-c.
This requires updates in appservices and changes to the uniffi-bindgen-gecko-js
parts.
appservices & uniffi-bindgen-gecko-js
will be handled by the a-s team though.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
NOT YET READY!
This is for local testing. It still requires:
- appservices update
mach vendor rust
- Changes to
uniffi-bindgen-gecko-js
- Running
mach uniffi generate
to update in-tree files
The duplicated deps will go away with the appservices update.
Comment 3•2 years ago
|
||
Some more steps for the Glean/A-S/UniFFI update:
- Updated to the app-services to the
uniffi-0.24
branch. - 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 vendor rust
- ran
mach uniffi generate
TODO:
- Fix the callback interface code (the unit test is currently failing)
- Merge the application-services
uniffi-0.24
branch and use a commit
frommain
instead. - There's a comment in
toolkit/library/rust/shared/Cargo.toml
about "rusqlite's bindings file", that I don't understand. Check if
any more action is needed here. - Double-check the
cargo vet
updates. I did this fairly blindly,
should some of the vettings have more info? Should I actually go
through the diff of theprost
changes?
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Ran mach vendor rust
and mach uniffi generate
. Checking this in as
a separate commit to simplify review.
Depends on D182286
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Backed out for causing multiple failures, incl. build bustages
Backout link: https://hg.mozilla.org/integration/autoland/rev/747c3656b20a9a6db50fdc17056093ca39f3624e
Assignee | ||
Comment 8•2 years ago
|
||
That's a tough one. I hit that earlier locally already, but thought (hoped?) we wouldn't hit that on CI (Ben didn't encounter this in his testing). This might be https://github.com/rust-lang/rust/issues/113104 -- I'm looking into how to mitigate it, and what we can report to rust.
Comment 9•2 years ago
|
||
Not usable as is, but this avoids the problem:
diff --git a/uniffi_meta/Cargo.toml b/uniffi_meta/Cargo.toml
index 3f4f0adb..df68955d 100644
--- a/uniffi_meta/Cargo.toml
+++ b/uniffi_meta/Cargo.toml
@@ -14,4 +14,3 @@ bytes = "1.3"
serde = { version = "1.0.136", features = ["derive"] }
siphasher = "0.3"
uniffi_checksum_derive = { version = "0.24.0", path = "../uniffi_checksum_derive" }
-uniffi_core = { path = "../uniffi_core", version = "=0.24.0" }
diff --git a/uniffi_meta/src/lib.rs b/uniffi_meta/src/lib.rs
index 074fdb20..4eaf69d8 100644
--- a/uniffi_meta/src/lib.rs
+++ b/uniffi_meta/src/lib.rs
@@ -16,6 +16,9 @@ pub use group::{group_metadata, MetadataGroup};
mod reader;
pub use reader::{read_metadata, read_metadata_type};
+#[path = "../../uniffi_core/src/metadata.rs"]
+mod metadata;
+
/// Similar to std::hash::Hash.
///
/// Implementations of this trait are expected to update the hasher state in
diff --git a/uniffi_meta/src/reader.rs b/uniffi_meta/src/reader.rs
index 037d1d01..2f2b2251 100644
--- a/uniffi_meta/src/reader.rs
+++ b/uniffi_meta/src/reader.rs
@@ -4,7 +4,7 @@
use crate::*;
use anyhow::{bail, Context, Result};
-use uniffi_core::metadata::{checksum_metadata, codes};
+use crate::metadata::{checksum_metadata, codes};
pub fn read_metadata(data: &[u8]) -> Result<Metadata> {
MetadataReader::new(data).read_metadata()
Comment 10•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
bugherder |
Description
•