Using #[derive_reprC] with derive attributes about safer_ffi HOT 7 CLOSED

Thanks for the clear explanation @danielhenrymantilla !

it needs to re-emit the given definition, which contradicts a derive implementation

This is a bit annoying. ReprC is not that similar with other traits that are easy to derive - it needs to modify the definition of struct to add repr annotation. Proc macro might be a better way in this regard.

from safer_ffi.

This situation will be improved soon when I move to total proc-macro implementations. In the meantime, moving the #[repr(...)] before other attributes (except for #[derive_ReprC]) ought to work 🙂

from safer_ffi.

Like so?

#[repr(i32)]
#[derive(PartialEq)]
#[derive_ReprC]
pub enum Fmi2Status {
    Fmi2OK,
    Fmi2Warning,
    Fmi2Discard,
    Fmi2Error,
    Fmi2Fatal,
    Fmi2Pending,
}

This also came to my mind, but I get the error:

error: macro attributes must be placed before `#[derive]`
  --> src\lib.rs:64:1
   |
64 | #[derive_ReprC]
   | ^^^^^^^^^^^^^^^

By the way, great work on the module :)

from safer_ffi.

Almost there 😄 :

#[derive_ReprC] // needs to be before the derives
#[repr(i32)] // needs to be the first attribute derive_ReprC sees (until I fix that)
#[derive(…)]
enum …

from safer_ffi.

Thank you that solved the issue, I could have sworn I already tried this 😆

from safer_ffi.

How about making ReprC trait derive-able like this?

from safer_ffi.

@waynexia Yeah, that might probably be doable once we perform the shift to fully procedural implementations; the crate started using macro_rules! macros, as in:

#[derive_ReprC]
struct Foo { x: i32 }
// becomes:
ReprC! {
    struct Foo { x: i32 }
}

and the latter, since it was supposed to also be a standalone-usable public macro, it needs to re-emit the given definition, which contradicts a derive implementation (which mustn't re-emit the given input, lest it appear twice, conflicting with one another).

Your suggestion would thus be covered by:

• #46

  The idea there is that there could be two approaches:

  #[derive(ReprC)]
  #[repr(C)] // <- error if missing repr
  struct …

  or:

  #[safer_ffi::repr(C)] // <- the attribute attaches its own repr
  struct …

  • _{^{The latter still "suffers" from the ordering issues mentioned in this very issue, but would be the more flexible approach, by allowing the attribute to attach repr, or other such attributes (should there appear more in the future), in a rather API-encapsulated way. That is, it would be the more future-proof approach. But we'll see what we end uo going for}}

from safer_ffi.