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

hide type detail when using type alias? #711

Closed
myrfy001 opened this issue Aug 27, 2021 · 3 comments
Closed

hide type detail when using type alias? #711

myrfy001 opened this issue Aug 27, 2021 · 3 comments

Comments

@myrfy001
Copy link

For the following rust code, with command cbindgen --lang C t.rs

type Context = HashMap<String, String>;

#[no_mangle]
pub extern fn new_context() -> *const Context{}

will generate the following C code:

typedef struct HashMap_String__String HashMap_String__String;

typedef struct HashMap_String__String Context;

const Context *new_context(void);

I don't want to let the enduser know the detail of Context is a HashMap_String__String, they should only know it's a type of Context, how can I do that?

Thanks

@emilio
Copy link
Collaborator

emilio commented Aug 27, 2021

struct Context (HashMap<...>) should work?

@myrfy001
Copy link
Author

It works! Thanks for the help~

@rlidwka
Copy link

rlidwka commented Feb 17, 2024

struct Context (HashMap<...>) should work?

Technically, newtypes are not guaranteed to have the same memory layout as their inner types, see rust-lang/rust#87868 (comment).

I would want to put repr(transparent) on that Context so Rust compiler doesn't do anything funny. But adding it would make struct transparent to cbindgen as well.

@emilio is there a way to tell cbindgen to ignore repr(transparent) or repr(C) directives, and make the struct opaque instead? I was looking for something like /// cbindgen:opaque annotation, but nothing like this seem to exist at the moment.

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

No branches or pull requests

3 participants