Allow generating a C header representing the exported symbols of a lib

[huonw]

For example,

#[crate_type="lib"];

pub struct Foo { x: i16 }

#[no_mangle]
pub extern "C" fn bar(x: u64) -> Foo { ... }

pub fn ignored() { ... } // wrong ABI

would correspond to

#ifndef FILENAME_H
#define FILENAME_H

#include<stdint.h>

struct Foo {
    int16_t x;
}

struct Foo bar(uint64_t);

#endif

so that one can call into Rust from C more easily.

(This is the inverse operation of the proposed #[header="stdio.h"] mod stdio; functionality for using libclang to read C headers into a form that rustc understands: #2124)

[alexcrichton]

Along the lines of this, I've heard that having a rust.h would be nice to have for things like:

typedef struct {
  void *data;
  uintptr_t len;
} RustSlice;

typedef struct {
  uintptr_t len;
  uintptr_t alloc;
  uint8_t data[0];
} RustString;

And other useful compiler definitions.

One tough part about this would be the C representation of FFI types, it would be really nice to able to interact with them from C, but our optimizations will nullable pointers and discriminant size may make them difficult.

[wycats]

👍

[alexcrichton]

I started a version of this at https://gist.github.com/alexcrichton/4ea33d9a8b19ed15a65a, but it's only the bare bones infrastructure for getting something like this up and running.

[zkamsler]

@alexcrichton That is pretty cool. You might want to stick to using the stdint.h typedefs for printing the integer types, since the widths can vary and the signed-ness of char is implementation defined.

[thehydroimpulse]

/cc me

[steveklabnik]

bindgen does some of this, but rust.h would be nice for FFIing into Rust for sure

EDIT: whoops, I thought bindgen did both, but it does not, thanks @huonw

[ArtemGr]

(Offtopic, kind of: Bindgen wasn't even a proper Rust crate, last time I checked, and building it on Debian was enough of a pain that I had to choose another route for my FFI needs. The wish to have bindgen-like functionality in Rust is, I think, primarily a wish to have it available everywhere. It could be satisfied with bindgen working as a proper Cargo dev-dependencies package able to generate the Rust stubs from a C header entirely from build.rs). Ups. That was a rant. : }

[tomjakubowski]

I have some WIP stuff here. https://github.com/tomjakubowski/custard/tree/dev I think last I left it, it may have been in the middle of a refactor.

It follows the same idea as rustdoc: walk the typed AST, filter out things the tool cares about, clean up the types a bit, and emit something (a header file). In all honesty, it might make sense to make this a rustdoc 'backend' or something (if you squint, a header file is just another kind of documentation).

[luser]

I'm sure everyone here is already aware, but the state of the art here appears to be rusty-cheddar: https://github.com/Sean1708/rusty-cheddar

[king6cong]

rusty-cheddar and rusty-binder aren't very active those days. Should this be a feature important enough for Rust to be maintained by rust-lang-nursery or such? @alexcrichton

[aturon]

Closing; this should be tackled by an external tool.

[pannous]

State of the art is now https://github.com/eqrion/cbindgen/