Support non-C calling conventions

[Michael-F-Bryan]

I'm trying to export some Rust functions as a DLL to be used in a larger application, but instead of the usual extern "C" calling convention, I'm using stdcall. With stdcall, cbindgen doesn't emit declarations.

Would it be possible to tweak the rules so cbindgen will make bindings for anything marked extern and #[no_mangle], no matter the calling convention? I don't think there's any time you wouldn't want bindings for a function marked extern.

This looks like it's related to #49, but affects all forms of extern, not just where the "C" is omitted.

[eqrion]

This seems reasonable to me.

What needs to be output for fn extern "stdcall"? Just __stdcall after the return type?

[Michael-F-Bryan]

According to msdn the syntax looks like this: return-type __stdcall function-name[(argument-list)]. I just tried this out on my Arch Linux and while clang compiles a dummy program just fine, gcc spits out a syntax error. Apparently gcc wants you to write __attribute__((cdecl)) instead.

I haven't used the C pre-processor for much more than conditional compilation and #include, is there a non-hacky way to make this work across different compilers and platforms?

Alternatively, you could add an extra flag to the config struct which takes a Option<CallingConvention> (where CallingConvention is an enum of GCC or MSVC) with the default being None. This would mean you need to explicitly choose how the calling convention should be rendered in a header file. Then you can add a pass before rendering to emit warnings if a non-C calling convention is detected and the user hasn't specified a CallingConvention.

---

Awesome project by the way. I originally made something similar because rusty-binder looked inactive, it's nowhere near as complete as cbindgen though!

[eqrion]

Hmm, so I think we can generate the following to handle this:

#ifndef _MSC_VER
// might need some fudging depending on where the attribute needs to go in the function declaration.
#define __stdcall __attribute__((stdcall))
#endif

Seeing as stdcall is a supported function attribute for gcc (and possibly clang). (1)

[Michael-F-Bryan]

That's quite a nice solution. I'm assuming those #defines will only be inserted if the corresponding calling convention is used? You may need some sort of lookup table which resolves a Rust extern "C" and friends to their clang/msvc/gcc counterparts (__cdecl or __attribute__((cdecl))).

I'll see if I can start working on a PR for this tomorrow.

[Michael-F-Bryan]

@eqrion, do you have anything in mind for how to add support for calling conventions into cbindgen? I've worked with syn in the past, so wrapping my head around how you extract a Function from its AST node was easy enough.

I think this is all I need to do to add support for calling conventions:

• tweak Function::load() to accept a syn::Abi and store it internally.
• update Function's Source::write() impl to actually write out the calling convention
• Make sure the ABI is detected and passed in
• Add some sort of flag to the configuration
• make sure macros are declared at the top if needed

... Is that about it?

[eqrion]

@Michael-F-Bryan Yes, that sounds reasonable to me.

You'll need to have a pass to detect what macros should be declared at the top, and it'd be best if this worked after we eliminated unused items (the dependency pass). That can most likely go in Library (1) where I've put other passes like that. Maybe accumulate them into a set of flags or a struct of bool fields that gets passed onto Bindings, where we write it out at the beginning?

Thanks for looking into this! The code isn't the best organized, it's evolved to support a bunch of random features people have wanted quickly.

[otavio]

We ended needing this feature as well but in our case we had to use extern "system" as it allow dynamic support for Win32 as well as Win64 and others.

From FFI nomicon:

Most of the abis in this list are self-explanatory, but the system abi may seem a little odd. This constraint selects whatever the appropriate ABI is for interoperating with the target's libraries. For example, on win32 with a x86 architecture, this means that the abi used would be stdcall. On x86_64, however, windows uses the C calling convention, so C would be used. This means that in our previous example, we could have used extern "system" { ... } to define a block for all windows systems, not only x86 ones.

It'd be great if we could handle this gracefully.

[JBarberU]

Hey, I realize this issue has been sitting here for a minute...

I'm hitting some issues while trying to port an existing C API to rust, using cbindgen. That original API used __stdcall on windows and I would prefer to do this for the rust port too. I managed to come up with a solution to adding __declspec(dllimport) to all function calls by adding a conditional define to csbindgen::Config::header and then cbindgen::FunctionConfig::prefix.

I'm currently stumped on getting __stdcall in behind the return type, and getting cbindgen to generate anything if I change my extern "C" fn -> extern "system" fn 🤔

I see the pull request #979 has been sitting unmerged for a while. Is there any chance that would get merged anytime soon?

I would love to be able to use cbindgen down the line and not have to manually patch the generated headers for each release of my library.