[Error] ReprC Implementation Not General Enough about safer_ffi HOT 5 CLOSED

Good news, the changes from that experimental branch have made it to master! On the other hand, master is not yet in a releasable-to-crates.io state, but that should be happening within the following weeks.

Closing this as completed, then 🙂

from safer_ffi.

As I look around, I'm getting the feeling that it's perfectly possible to implement ReprC for the struct, but that the macro just doesn't have the proper for<'a, 'b> thing ( higher-kinded trait bound, if I remember right ). Is there an easy-enough way to manualy implement ReprC for that struct so that I don't need the macro and I can do it properly?

from safer_ffi.

Hey, I think using cargo exand I've figured out what code the macro is trying to expand to, and it seems like this is equivalent, and works as far as my initial testing ( compiling and running it 😉 ):

#[repr(C)]
#[derive(Clone, Copy)]
pub struct CHostFunctionPointers {
    /// Get the full CBOR serialized [`ScriptApi`] including components discovered and
    /// implemented by other language adapters or the dynamite host.
    pub get_full_api: extern "C" fn(dynamite: *const Void) -> repr_c::Vec<u8>,

    /// Call a function provided by the scripting API
    call_function: extern "C" fn(
        dynamite: *const Void,
        path: str::Ref<'_>,
        args: c_slice::Ref<'_, *const Void>,
    ) -> *const Void,
}
unsafe impl safer_ffi::layout::CType for CHostFunctionPointers {
    type OPAQUE_KIND = safer_ffi::layout::OpaqueKind::Concrete;
}
unsafe impl safer_ffi::layout::ReprC for CHostFunctionPointers {
    type CLayout = Self;
    #[inline]
    fn is_valid(_: &Self::CLayout) -> bool {
        true
    }
}

I have no idea if it makes sense 😜.

from safer_ffi.

Yes, as you have correctly identified, this is an issue related to function pointer with different "higher-order-ness" requiring different generic signatures to be covered; see:

• this being a "known language issue" (and how there is a desire to, ultimately, have the language support it),

• My talking about this in another crate, and how I circumvented the issue by providing a helper macro for users to implement the trait for their own function (pointer) signatures;

This is thus a known issue of safer-ffi, which you can find at #16. It has been marked as resolved, since in the main development branch (ditto), a workaround similar to that of that crate has been used. I have even written about it in the following gist: https://gist.github.com/danielhenrymantilla/be45a92cb6ad8b177cc28eda9c7f2004#why-are-higher-order-lifetimes-challenging-for-safer-ffi

I haven't release that officially since I need to untangle this kind of features with some development / experimental features present in the ditto branch. But, provided you pin-point a commit within the ditto branch, I assure you I won't rewrite the history of that branch and so you should have a "stable" / smooth experience with it anyways:

Temporary solution

• # Cargo.toml
  [dependencies.safer-ffi] # (or use `[patch.crates-io.safer-ffi]`)
  git = "https://github.com/getditto/safer_ffi"
  branch = "ditto"
  rev = "fa26bdd4cfbdeee282ed4b420b46a5e2fecd3739"
  features = ["proc_macros"]

• #![deny(elided_lifetimes_in_paths)] // the macro needs explicit lifetime parameters, even if elided, to work.
  
  #[derive_ReprC]
  #[repr(transparent)]
  struct call_function_t /* = */ (
      unsafe extern "C" fn(
          dynamite: *const Void,
          path: str::Ref<'_>,
          args: c_slice::Ref<'_, *const Void>,
      ) -> *const Void
  );
  
  #[repr(C)]
  #[derive(Clone)]
  pub struct CHostFunctionPointers {
      /// Get the full CBOR serialized [`ScriptApi`] including components discovered and
      /// implemented by other language adapters or the dynamite host.
      pub get_full_api: unsafe extern "C" fn(dynamite: *const Void) -> repr_c::Vec<u8>,
  
      /// Call a function provided by the scripting API
      call_function: call_function_t,
  }

An official release of safer-ffi improving most of these rough edges (naming, higher-order fns, etc.) is planned within the next 1-2 months, anyways 🙂

from safer_ffi.

Awesome! Thanks for the help!

from safer_ffi.