Added the `uniffi:ffi-trace` feature. If enabled, UniFFI will printout
tracing-level logs for FFI calls. I hooked up the futures code to this,
in the future we could also log more stuff. Lowering/lifting/cloning
arcs is the first example that comes to mind.
To see tracing, use the `--features=ffi-trace` when running a tests, for example:
- `cd fixtures/futures/src`
- `cargo test --features=ffi-trace`
Here's an example of the tracing printouts when running tests from the
futures fixtures:
```
rust_future_new: Handle(94402427620656)
rust_future_poll: Handle(94402427620656)
RustFuture::wake called
rust_future_poll: Handle(94402427620656)
RustFuture::poll is ready (canceled: false)
rust_future_complete: Handle(94402427620656)
rust_future_free: Handle(94402427620656)
```
* Thread `ExternalType` metadata into RustBuffer
In service of Java bindgen being able to generate fully qualified
`RustBuffer`s when necessary.
* Switch to `test --no-run` from `build` for cdylib
`uniffi-bindgen-java` is external to the uniffi repo, so the
fixtures/examples are all `dev-dependencies`, which aren't built on a
call to `cargo build`. `cargo test --no-run` causes them to be built but
doesn't cause a run of tests in place.
This continues the cargo_metadata feature work but making the execution
of cargo_metadata the resonsibility of the uniffi_bindgen callers
rather that executing it implicitly. This means the CLI,
which in-turn means the top-level uniffi crate also gets a
`cargo-metadata` feature.
This reverts what we did to fix#2183 - by making `no_deps` the
default, it means we will be unable to support reuse of UniFFI
components, because it means we only support all components
being in the same workspace. While this is a common use-case,
it's not the only use-case we want to support. So grabbing
all dependencies from cargo_metadata is again the default, but
there's a new command-line option to avoid it.
It also replaces some of #2195.
With crate mode, the user specified a crate name and UniFFI handled
building it. With library mode the user needs to build the library
themselves, then pass the path to UniFFI.
This is slightly less convenient for the user -- although not that much,
since somewhere in their build system they are going to need to build
the library and copy it out. However, it's more flexible since users can
build their library with whatever combination of feature flags, targets,
etc. they want, and if this affects the generated bindings UniFFI will
work with it. Before, UniFFI had to guess the flags to pass to `cargo
build`, which wasn't ideal.
Made a few doc changes to indicate that library mode is the recommended
way to build and will probably be the default sometime in the future.
However, for now it's still not the default.
Fixed some newer fixtures to use `include_scaffolding!()`
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 `benchmarks` fixture. This runs a set of benchmark tests
and uses `criterion` to analyze the results. Added some benchmarks
for calling functions and callback interfaces.
- Added `run_script()` function, which is a more generic version of
`run_test()`.
- uniffi_testing: Don't add `--test` when running `cargo build` to find
the dylibs. It's not needed for the fixture/example tests and it
breaks the benchmark tests.
This code assumes that all generate files will be compiled into a single
module, which makes external type support quite trivial.
- Updated the swift testing code to handle multiple UDL files.
- Made the custom type, enum, object, and record, FfiConverters public
to allow them to be used with external types.
- Made the FfiConverter methods public. I didn't make the protocols
themselves public, since that would result in duplicate definitions
when different UniFFI-generated swift files were linked together, but
I did make each individual method public.
- Added Swift external types tests.
- Fixed a bug in the CustomType template. I'm pretty sure we should be
using `type_ffi_lowered` instead of `ffi_type_name` there since it's
Swift code rather than a C header file.
- Added docs for configuring external types
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>
* 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>
Ben Dean-Kawamura
Mark Hammond
Murph Murphy
Didier Villevalois
Jan-Erik Rediger
messense
Jonas Platte
Tarik Eshaq