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

Created on 17 Nov 2013 · 11Comments · Source: rust-lang/rust

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: https://github.com/mozilla/rust/issues/2124)

A-ffi C-enhancement

Source

huonw

👍1

Most helpful comment

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

luser on 11 Apr 2016

👍5

All 11 comments

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.

alexcrichton on 17 Nov 2013

:+1:

wycats on 13 Jan 2014

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.

alexcrichton on 31 May 2014

@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.

zkamsler on 31 May 2014

/cc me

thehydroimpulse on 31 May 2014

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

steveklabnik on 21 Apr 2015

(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. : }

ArtemGr on 21 Apr 2015

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).

tomjakubowski on 9 Jun 2015

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

luser on 11 Apr 2016

👍5

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