Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support cfg_attr with repr() and no_mangle #183

Open
boozook opened this issue Jul 30, 2018 · 3 comments
Open

support cfg_attr with repr() and no_mangle #183

boozook opened this issue Jul 30, 2018 · 3 comments

Comments

@boozook
Copy link

boozook commented Jul 30, 2018

#[cfg_attr(feature = "cffi", repr(C))]
#[cfg_attr(feature = "cffi", no_mangle)]
pub struct Token { foo: u8 }

cbindgen.toml:

language = "C"

[export]
include = [ "Token" ]

[parse]
parse_deps = false

[defines]
feature = "cffi"

> cbindgen -v -c ./cbindgen.toml -o ./include.h

So cbindgen sayd "INFO: Take api::Token - opaque (Struct is not marked #[repr(C)].)." and the output include.h is empty.

@regexident
Copy link
Contributor

Recognizing every possible attribute is kind of a lost cause, due to procedural attribute macros.

Case in point: https://github.com/regexident/apply_attr

Fortunately for those things there is cbindgen's expand feature for the rescue …

[parse]
expand = ["crate-name"]

… which will properly resolve your example, even without your PR #189.

Using [parse.expand] for all crates by default would solve this whole bag of issues, I think.
What would be the down-side of expand by default, @eqrion? Performance, I guess?

@eqrion
Copy link
Collaborator

eqrion commented Aug 18, 2018

Using [parse.expand] by default is, unfortunately, not desirable for all use cases. Off the top of my head the top caveats are:

  1. Is slow
  2. Requires rustc nightly and depends on an unstable feature
  3. Can cause infinite recursion in build scripts
  4. Not easy (impossible?) to handle circular dependencies when used with rust-bindgen

But I agree, ideally we'd have the rust compiler figure out as much of this stuff as possible. Until that's ever feasible, this crate is going to try to be good enough for most sane use cases.

@regexident
Copy link
Contributor

Thanks for the response, @eqrion!

But I agree, ideally we'd have the rust compiler figure out as much of this stuff as possible. Until that's ever feasible, this crate is going to try to be good enough for most sane use cases.

Given the caveats listed this is more than reasonable. :)

A simple actionable workaround for such hard to catch meta-attributes might be to add support for adding defines via annotation 🤔 :

// cbindgen: DEFINE=THAT_MAGICAL_PROC_MACRO
#[cfg_attr(feature = "magic", a_proc_macro_that_generates_more_attributes)]
pub struct Token { foo: u8 }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants