Par example,
#[crate_type="lib"];
pub struct Foo { x: i16 }
#[no_mangle]
pub extern "C" fn bar(x: u64) -> Foo { ... }
pub fn ignored() { ... } // wrong ABI
correspondrait à
#ifndef FILENAME_H
#define FILENAME_H
#include<stdint.h>
struct Foo {
int16_t x;
}
struct Foo bar(uint64_t);
#endif
afin que l'on puisse appeler Rust depuis C plus facilement.
(C'est l'opération inverse de la fonctionnalité #[header="stdio.h"] mod stdio;
proposée pour utiliser libclang pour lire les en-têtes C sous une forme que rustc comprend : https://github.com/mozilla/rust/issues/2124)
Dans le même ordre d'idées, j'ai entendu dire qu'avoir un rust.h
serait bien d'avoir des choses comme :
typedef struct {
void *data;
uintptr_t len;
} RustSlice;
typedef struct {
uintptr_t len;
uintptr_t alloc;
uint8_t data[0];
} RustString;
Et d'autres définitions de compilateur utiles.
Une partie difficile à ce sujet serait la représentation C des types FFI, ce serait vraiment bien de pouvoir interagir avec eux depuis C, mais nos optimisations auront des pointeurs nullables et la taille discriminante peut les rendre difficiles.
:+1:
J'ai commencé une version de ceci à https://gist.github.com/alexcrichton/4ea33d9a8b19ed15a65a , mais ce n'est que l'infrastructure de base pour faire fonctionner quelque chose comme ça.
@alexcrichton C'est plutôt cool. Vous voudrez peut-être vous en tenir à l'utilisation des typedefs stdint.h
pour imprimer les types entiers, car les largeurs peuvent varier et la signature de char
est définie par l'implémentation.
/cc moi
bindgen fait une partie de cela, mais rust.h
serait bien pour FFIing dans Rust à coup sûr
EDIT : oups, je pensais que bindgen faisait les deux, mais ce n'est pas le cas, merci @huonw
(Hors sujet, en quelque sorte : Bindgen n'était même pas une bonne caisse Rust, la dernière fois que j'ai vérifié, et le construire sur Debian était assez pénible pour que je doive choisir un autre itinéraire pour mes besoins FFI. Le souhait d'avoir un bindgen-like la fonctionnalité dans Rust est, je pense, principalement un souhait de l'avoir disponible partout.Il pourrait être satisfait que bindgen fonctionne comme un package Cargo dev-dependencies
approprié capable de générer les stubs Rust à partir d'un en-tête C entièrement à partir de build.rs
). UPS. C'était une diatribe. : }
J'ai des trucs WIP ici. https://github.com/tomjakubowski/custard/tree/dev Je pense que la dernière fois que je l'ai laissé, il était peut-être au milieu d'un refactor.
Il suit la même idée que rustdoc : parcourez l'AST typé, filtrez les éléments qui intéressent l'outil, nettoyez un peu les types et émettez quelque chose (un fichier d'en-tête). En toute honnêteté, il pourrait être judicieux d'en faire un "backend" rustdoc ou quelque chose comme ça (si vous plissez les yeux, un fichier d'en-tête n'est qu'un autre type de documentation).
Je suis sûr que tout le monde ici est déjà au courant, mais l'état de l'art ici semble être le cheddar rouillé : https://github.com/Sean1708/rusty-cheddar
le rusty-cheddar et le rusty-binder ne sont pas très actifs ces jours-ci. Cela devrait-il être une fonctionnalité suffisamment importante pour que Rust soit maintenu par rust-lang-nursery ou autre ? @alexcrichton
Fermeture; cela devrait être traité par un outil externe.
Commentaire le plus utile
Je suis sûr que tout le monde ici est déjà au courant, mais l'état de l'art ici semble être le cheddar rouillé : https://github.com/Sean1708/rusty-cheddar