Docstrings rarely have unicode characters so these are not adding much
value. They present an issue for the downstream moz-central crate
(https://bugzilla.mozilla.org/show_bug.cgi?id=1894888), so let's remove
them.
Docstrings rarely have unicode characters so these are not adding much
value. They present an issue for the downstream moz-central crate
(https://bugzilla.mozilla.org/show_bug.cgi?id=1894888), so let's remove
them.
* Add missing derive feature to serde dependency
The code built without this, but that seems to because of an accident
since the derive feature is not a default serde feature.
I noticed this when trying to make uniffi_build an optional
dependency of uniffi_macros — for some reason I don’t understand, this
would make `cargo build -p uniffi_macros` fail wtih:
error: cannot find derive macro `Deserialize` in this scope
--> uniffi_macros/src/util.rs:29:14
|
29 | #[derive(Deserialize)]
| ^^^^^^^^^^^
|
The error makes sense since the derive feature wasn’t enabled. What
does not make sense to me is that the error wasn’t triggered before.
* Make `uniffi_build` optional in `uniffi_macros`
As far as I can see, the dependency on uniffi_build is not needed for
the macros used by regular clients of UniFFI — it is only used to
create a convenience macro for the UI tests.
I named the new feature “trybuild” after the description of the macro.
Please let me know if you have preferences for a better name.
The overall goal here is to minimize the number of crates I need to
vendor to use UniFFI — I’m hoping to get away with checking in the
generated target language sources, so I’m currently focusing on the
dependencies in the rest of the code base.
Docstrings are declared in .udl file by prefixing a line with three
slashes ///. Docstrings can be placed basically anywhere - functions,
objects, methods, constructors, callbacks, etc.. A docstring placed in
a wrong place will generate UDL parser error.
This leverages the new macro metadata feature to simplify bindings
generation. The new mode is enabled by passing `--crate [main-crate]`
to the `generate` command instead of a UDL file. UniFFI will then use
the exported metadata symbols cargo metadata to figure out what to
generate. Bindings will be generated for main crate and all it's
UniFFIed dependencies into a single out dir.
The new system allows us to set defaults for several config values that
should work in virtually all cases. `cydlib_name` can be calculated
from the dylib path that cargo metadata gives us.
`kotlin.external_packages` can be calculated since we're going to be
generating bindings for those external packages in the same pass.
I think this should improve use-cases like the app-services megazord,
where multiple UniFFI crates, including support crates, are compiled
into one large library. It makes it much simpler to add new crates or
to move types into a support crate and use the external types feature:
- No need to add a new `uniffi-bindgen` task to the build process
- No need to add a `uniffi.toml` config just to spcify the dylib name.
- No need to figure out the `external_packages` map for external
packages.
Made the generate command more verbose, for example it now prints out
the files it's generating. I found this very useful when debugging
generation issues and figured it would be nice going forward.
- Added the `uniffi_core::metadata` module, which provides a system for
building metadata buffers using const code.
- Added the `FfiConverter::TYPE_ID_META` const, which holds metadata
to identify the type.
- Made the proc-macros generate use the new system to generate metadata
consts, then export them using static variables.
- Removed the current code to generate/store metadata based on the syn
parsing.
- Removed the type assertions and the requirement for a `uniffi_types`
module. We don't need them now that we`re getting the type ids from
the type itself.
- Made the `FnMetadata.throws` field a Type rather than a String.
- Calculate module paths with the `module_path!()` macro. This means we
get accurate module paths without nightly. Changed mod_path to be a
String, rather than a Vec since this is what `module_path!()` outputs.
- Added code to strip the `r#` part out of raw idents before serializing
it into the metadata.
- Replaced the `collect_params()` function with the `ScaffoldingBits`
struct. There was too much complexity for a single function -- for
example unzip() only works with pairs, not 3-tuples.
In general, the new metadata system is more reliable doing everything in
the proc-macros. Proc-macros can only see the type identifiers, but
they don't anything about the underlying type, since users can rename
types with type aliases. It's also simpler since you don't have to walk
the AST so much.
One TODO is getting checksum working again. One limitation of the const
code is that we can't use it to generate function identifiers.
This removes the clap dependency on `uniffi_bindgen` which is nice for
consumers that want to just use the Rust API.
This completes the migration of the CLI from `uniffi_bindgen` to
`uniffi`
The new system has several advantages:
- It has handling for external crates, which makes the python
ext-types fixtures work again.
- It uses the correct suffix for Swift modules (#1194)
- It doesn't require the `uniffi::testing` module, which I think will
help #1374
This means that the example/fixture crates need to take a dev-dependency
on `uniffi_bindgen`. I also updated several to take a dev-dependency on
`uniffi_macros` instead of a regular dependency, since they only needed
it for the tests. The required change was making sure all the crates had
a `lib` crate-type.
While updating the bindings code to use `uniffi_testing`, I also moved
it into its own module.
* Allow Rust, Python and Kotlin keywords to be used as identifier names. (#1237)
* New regression test: We missed a newline
This is already fixed in `main`, but was an issue in 0.19.1
* Include the askama config file into the build
* Adding changelog entry for the Askama fix
* Disable publish for keyword fixtures (#1289)
* (cargo-release) version 0.19.2
* Extend regression test to Swift, Kotlin & Ruby
* Don't strip newlines around function definitions
Applies to Kotlin, Ruby and Swift.
Kotlin didn't actually break.
Co-authored-by: Travis Long <tlong@mozilla.com>
* (cargo-release) version 0.19.4
* Remove the r# added in 0.19.4
* (cargo-release) version 0.19.5
Co-authored-by: Mark Hammond <mhammond@skippinet.com.au>
Co-authored-by: Jan-Erik Rediger <jrediger@mozilla.com>
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Co-authored-by: Ben Dean-Kawamura <bdk@mozilla.com>
Co-authored-by: Travis Long <tlong@mozilla.com>
The nice thing about this system is that the metadata is always bundled
together with the build output. This makes it easier to ensure that the
generated scaffolding matches up with the dylib that it's going to be link to.
This avoids the work that `rebuild_metadata()` needed to do. Metadata
is serialized with bincode to keep the binary size reasonable.
The downside is that we need to parse a dylib, which feels slightly
risky. However, it seems less risky overall to me, since we don't have
to worry about tracking the JSON files -- especially after fixing the
recent the sccache issue. Also, extracting the symbol data with the
goblin crate is not that bad, see `macro_metadata/extract.rs` for how
it's done.
In order to use the macro metadata, you now need to specify `--cdylib
[path-to-library]` when running `uniffi-bindgen`. This is annoying, but it
will be simpler once the proc-macros can handle all parts of the interface.
At that point, we can make `uniffi-bindgen` accept either a UDL path or a cdylib
path as it's positional arg.
I didn't add support for external bindings to pass in a cdylib path, since
adding an argument to that function would be a breaking change, then we would
need to do another breaking change to make the param `udl_or_cdylib_file`. If
external bindings really want to, they can call
`uniffi_bindgen::interface::macro_metadata::add_to_ci` directly.
Added the `uniffi-bindgen dump-json` command that inputs a cdylib path and
prints the matadata as JSON.
I tested that `dump-json` works properly on the following targets:
- x86_64-unknown-linux-gnu (ELF 64-bit)
- i686-unknown-linux-gnu (ELF 32-bit)
- x86_64-apple-darwin (Mach-O 64-bit)
- x86_64-pc-windows-gnu (DLL 64-bit)
- i686-pc-windows-gnu (DLL 32-bit)
This seems like good enough coverage to me, although there are a lot of other
systems that would be nice to test on. The limiting factor was setting up the
cross-compilation toolchains on my machine. Maybe we should add some more CI
platforms that just run macro-metadata-related tests.
Updated the testing code to pass the cydlib path, rather than the
directory that contains it.
Added an enum that covers all Metadata types. This is what we serialize
in the cdylib.
* Allow Rust, Python and Kotlin keywords to be used as identifier names. (#1237)
* New regression test: We missed a newline
This is already fixed in `main`, but was an issue in 0.19.1
* Include the askama config file into the build
* Adding changelog entry for the Askama fix
* Disable publish for keyword fixtures (#1289)
* (cargo-release) version 0.19.2
* Extend regression test to Swift, Kotlin & Ruby
* Don't strip newlines around function definitions
Applies to Kotlin, Ruby and Swift.
Kotlin didn't actually break.
Co-authored-by: Travis Long <tlong@mozilla.com>
* (cargo-release) version 0.19.3
Co-authored-by: Mark Hammond <mhammond@skippinet.com.au>
Co-authored-by: Jan-Erik Rediger <jrediger@mozilla.com>
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Co-authored-by: Travis Long <tlong@mozilla.com>
* Allow Rust, Python and Kotlin keywords to be used as identifier names. (#1237)
* New regression test: We missed a newline
This is already fixed in `main`, but was an issue in 0.19.1
* Include the askama config file into the build
* Adding changelog entry for the Askama fix
* Disable publish for keyword fixtures (#1289)
* (cargo-release) version 0.19.2
Co-authored-by: Mark Hammond <mhammond@skippinet.com.au>
Co-authored-by: Jan-Erik Rediger <jrediger@mozilla.com>
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>