tomleavy/safer-ffi-gen

Attribute macro to help automate Rust FFI bindings

safer-ffi-gen's Issues

Support `no_std` for generated code

Move macro crate to safer-ffi-gen-macro

1. Move macro to a dependency crate
2. Make the main crate re-export the macro crate

Support other executors besides `tokio`

Ideally, support any executor.

The motivation is embedded projects which may have constraints on the executor to use.

Code generation of ffi functions

1. Convert inputs to actual rust types
2. Call original method
3. Convert result to FFI type and return

Fix invocation requirements

safer_ffi_gen should be able to be used in all cases. It is a no-op when called within a module that is also marked.

Currently using safer_ffi_gen_func as a marker just to get things started

Support &str

use safer_ffi::prelude::str

Generate exported function to clone types that support it

Start path with :: to avoid module conflicts

Should the path start with ::safer_ffi to make sure it picks up only external crates and not modules?

Originally posted by @stefunctional in #15 (comment)

Consider changing the case conversion crate

convert_case turns FooI32 into foo_i_32 for snake-case, instead of foo_i32. heck gives the expected output.

Generate `free` functions for types that don't derive `FfiType`

FfiType takes of generating a free function for the type it is derived for. However, types like Vec<u8> (and more generally Vec<T>) or String also need freeing.

Define derive/attr-macro for `FfiType`

This should:

• Implement FfiType
• If possible, take care of Drop (#19) and Clone (#20)

Allow specialization in separate module

Allow calling safer_ffi_gen::specialize in a different module from the one containing the impl block.

Investigate compatibility with maybe-async

safer_ffi_gen looks at the async keyword on functions before maybe_async has a chance to remove it if building with the is_sync feature. This causes the function generated by safer_ffi_gen to forward incorrectly the call to the original function as if it were async.

Support opaque types

Opaque types should be boxed when passed or returned by value.

Add trait to aid with type conversions

Make a trait that has an associated type so we can just print that directly instead of guessing based on the name of the struct

Describe ownership of parameters and return value in documentation of generated functions

C functions generated by safer-ffi-gen may take or return pointers, but it is not clear when these pointers transfer ownership. E.g.:

• Should the caller free the pointer returned by a function?
• Can a pointer passed to a function be used after the call, or does the function take ownership of the pointee?

While this information is lost in the C signatures, it is present in the Rust signatures (borrows vs owned values), so it seems that it should be possible to extract it and add it to the documentation of the generated C functions.

Support non-blocking async via `tokio`

A C callback should be fired when tokio_spawn is done with the inner function that contains a custom result type if needed that can help users understand if there was an error or not.

Alternative:

on_success and on_failure

Support enumerations with data

It should be possible to expose them as an opaque type (not exposing the variants as safer-ffi does for C-like enums). Probably blocked on support in safer-ffi unless we try to implement ReprC ourselves.

Consider splitting slice parameter into 2 parameters

A slice parameter is translated to a struct with two fields: a pointer and a length. For a more idiomatic C experience, consider inlining these 2 fields as 2 parameters in the call.

Support slice

use safer_ffi::prelude::c_slice

Support conditional compilation for `impl` blocks

Problem

To expose functions through FFI, safer-ffi-gen requires adding the attribute macro safer_ffi_gen to the impl block and to annotate each function to expose with #[safer_ffi_gen], i.e.:

#[safer_ffi_gen]
impl Foo {
    #[safer_ffi_gen]
    pub fn foo() {}

    pub fn bar() {}
}

In the above example, foo is exposed through FFI but bar isn't. Note that while #[safer_ffi_gen] on each function looks like an attribute macro, it isn't. It is just an arbitrary token list that is recognized and removed by the #[safer_ffi_gen] macro call on the impl block.

This setup falls apart when making the FFI support conditionally compiled. First failed attempt:

#[cfg_attr(feature = "ffi", safer_ffi_gen)]
impl Foo {
    #[safer_ffi_gen]
    pub fn foo() {}

    pub fn bar() {}
}

When the ffi feature is off, the annotation on foo isn't removed and thus the code does not compile. Second failed attempt:

#[cfg_attr(feature = "ffi", safer_ffi_gen)]
impl Foo {
    #[cfg_attr(feature = "ffi", safer_ffi_gen)]
    pub fn foo() {}

    pub fn bar() {}
}

This fails to compile because the outer safer_ffi_gen attribute only recognizes functions marked exactly with #[safer_ffi_gen]. So in this case it leaves the inner cfg_attr as-is, and that causes the inner safer_ffi_gen macro to run on the fn foo function, which leads to an error because this macro is meant to be applied to an impl block instead of a function. Despite looking identical, #[safer_ffi_gen] on a function is only an arbitrary marker to be consumed by the #[safer_ffi_gen] macro on the impl block.

Solutions

The attribute on the impl block is required because this is the only way to get the type name and generics.

Solution 1

The marker on functions could be removed and all functions in an impl block with the attribute #[safer_ffi_gen] would be exposed through FFI. The drawback of this approach is that it forces users to segregate functions in different impl blocks based on whether they needs to be exposed through FFI. That can be a more invasive change for an existing codebase. An advantage of this solution is that it is easier to add to the existing safer-ffi-gen implementation.

#[cfg_attr(feature = "ffi", safer_ffi_gen)]
impl Foo {
    pub fn foo() {}
}

impl Foo {
    pub fn bar() {}
}

Solution 2

The safer_ffi_gen macro could be changed to handle both an impl block and a function. When given an impl block, it would inject the type name and generics into the safer_ffi_gen attribute on functions inside the impl block. This solution requires more work but provides more flexibility to users to arrange their functions.

The code would be written as follows:

#[cfg_attr(feature = "ffi", safer_ffi_gen)]
impl Foo {
    #[cfg_attr(feature = "ffi", safer_ffi_gen)]
    pub fn foo() {}

    pub fn bar() {}
}

The expansion of the outer attribute would give something like:

impl Foo {
    #[cfg_attr(feature = "ffi", safer_ffi_gen(Foo)]
    pub fn foo() {}

    pub fn bar() {}
}

Convert receiver to ffi type

Currently receivers &self self etc are not supported. These should be converted to parameters of the FFI method

Add trait support for standard c types

Use basic types safer_ffi already supports such as i32 etc

Blocking async support via `tokio`

Async calls can be supported by using spawn_blocking internally instead of having a callback

Support `Option<T>` where `T` does not have a niche

We have a use case where a function returns Option<u64>. safer-ffi currently supports Option<T> when T has a niche (to represent the None case), which is not the case of u64.

Support `Option<T>`

Option works as a passthrough, but we need support for it defined

Support convert `Result<T>` into `Out`

The pattern for a result should be a function that has any output as Out and the function returns c_int.

There should also be a thread local err that you can get an error message from as a string with a function call

Support non-opaque struct types

E.g. wrappers around int types, or structs whose fields all have a repr(C) type.

Add some tests to safer-ffi-gen-macro

Basic testing to ensure that the output actually is valid

Generate exported function to call drop for types that need it

This includes (at least) opaque types.

Convert [no_mangle] to [safer_ffi::ffi_export]

Currently [no_mangle] is being used for easier debugging

Fix `#[repr(transparent)]` support

It seems to be limited to types with a niche (e.g. Box<T>) in safer-ffi 0.0.10. 0.1.0-rc1 addresses that, so let's try to update when it gets officially released. Support in safer-ffi-gen should already be implemented, so this task is mainly/entirely about adding a test.

Consider supporting a custom prefix for generated identifiers

In C, functions and types defined by a library often share a custom prefix identifying the library (thus emulating namespaces and avoiding name collisions). It would be helpful to support this.

An easy way is to specify this prefix everywhere one of our macros is used, but being able to define this prefix once and have it applied everywhere would be nice.