Generate C code to export static inline functions

[jrmuizel]

https://github.com/intelxed/xed has a bunch of inline functions as part of its interface. In order to make the xed bindings usable (valarauca/xed-sys#1) we need to export them somehow. If bindgen could generate C code that just wraps the static inline functions we would be able to use bindgen to generate bindings to that code which would solve the problem.

[emilio]

For now, you can also compile it with -fno-inline-functions, I think.

[jrmuizel]

Won't that prevent inlining inside xed?

[jrmuizel]

Further, -fno-inline-functions and .generate_inline_functions(true) doesn't actually seem to generate bindings for those functions. Perhaps because they are static inline?

[emilio]

Won't that prevent inlining inside xed?

Yup, I think so, which is unfortunate, I agree.

Further, -fno-inline-functions and .generate_inline_functions(true) doesn't actually seem to generate bindings for those functions. Perhaps because they are static inline?

Yeah, if they aren't visible in other translation units we can't generate symbols for them... I guess wrapping them is the best solution then

[jrmuizel]

What's the best approach to implement this?

[jrmuizel]

It looks like currently static inline functions end up in the ir with a name of None.

[fitzgen]

-fkeep-inline-functions should allow the functions to remain inlined at call sites, but still give us something to link to, IIUC.

---

This feature is something I've wanted for a while, but haven't had the need to actually implement. The biggest open questions I have are:

• How are we going to integrate this feature with our test suite? Emit tests/expectations/tests/whatever.c next to tests/expectations/tests/whatever.rs?

• What will the user ergonomics be like? Can we compile the emitted C for the user automatically from build.rs? As much as possible, I'd like to avoid users having to manually add new dependencies on things like gcc or cmake crates and add even more stuff to their build.rs.

---

What's the best approach to implement this?

A new pass over the final IR, probably called from inside ir::context::BindgenContext::gen right before or after our existing codegen. This should probably live in a new module next to codegen and ir named cgen or inlgen something like that but better :-p

It would be awesome if there was a c_quote! { ... } macro... but that's a pretty tall order if one doesn't exist already.

It looks like currently static inline functions end up in the ir with a name of None.

Unfortunately, I don't have any insight into why this might be off the top of my head.

[jrmuizel]

It looks like currently static inline functions end up in the ir with a name of None.

Unfortunately, I don't have any insight into why this might be off the top of my head.

This is fixed with #1091

I'm probably not going to look at this again anytime soon as I've switched from using https://github.com/valarauca/xed-sys/ to https://github.com/zyantific/zydis-rs which doesn't have this problem.

[kmod-midori]

static inline functions are still not generated with the option enabled when I tested on mbedTLS.