This is a `uniffi-bindgen` variant dedicated to Swift code, with options
specialized for Swift. I'm currently thinking that we should consider
doing this for all languages. In addition to allowing specialized
options, it also makes the in-tree bindings less special-cased compared
to external bindings.
Some of these could be made internal, but most could not. The reason is
that UniFFI code needs to import them from other modules in order to
support external types. This change mostly adds docstrings/annotations
to hide them from the generated docs.
For swift, this needed to behind an `#if` statement to keep
compatability with 5.5. Maybe we can up the minimum version with the
next breaking release.
The `n_sect` field is 1-based with `0` meaning `NO_SECT` meaning the
symbol is not present in any section in the library. This change fixes
the index mismatch.
Reference: https://github.com/aidansteele/osx-abi-macho-file-format-reference#nlist_64,
The code was mostly working before because of the way we calculate the
offset (2e3b59cf6d/uniffi_bindgen/src/macro_metadata/extract.rs (L106)). Because of this, even if we were off by one when picking the section, things would still work as long as the two sections involved lined up correctly.
Thanks to 0c0w3 for pointing this out and sending me the patch.
I want to use this in a CLI tool that I'm building. The uniffi crate
currently re-exports `generate_bindings`, but not
`library_mode::generate_bindings`.
See https://github.com/mozilla/uniffi-rs/pull/2175/files#r1749374986. That PR added a filter on `cargo_metadata`'s `is_lib`. While it makes sense to ignore non-library targets here, `is_lib` only returns `true` if the crate has the `lib` type, but not e.g. for `staticlib`, `cdylib` etc. In that case none of the targets match and the crate's `uniffi.toml` gets ignored.
I don't believe multiple modulemaps are useful at all. At Mozilla, we
end up deleting all the generated module maps and hand-writing one of
our own. Once this lands, I think we will be able to delete that code
and use the single generated modulemap.
The generate_bindings docs mentioned wanting to expose a function that
just finds ComponentInterface and config tables for each component and
leaves the rest to the external bindings generator. This is exactly
what I want to use for uniffi-bindgen-gecko-js.
The `find_components` function was pretty much exactly what we wanted.
I made some minor changes to it and exposed it as a pub function.
I'm hoping to do a 0.28.1 release and these would be good to have in it.
I also considered adding an entry for the work that mgeisler has been
doing, but I couldn't think of a good wording for that.
* 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.
bendk
Mark Hammond
Alex Kirszenberg
Samuel Tardieu
Christopher Schramm
Bastian Gruber
Bastian Gruber
Kristupas Antanavičius
Jan-Erik Rediger
Yury Yarashevich
Murph Murphy