Rust: Autoriser la génération d'un en-tête C représentant les symboles exportés d'une bibliothèque

Créé le 17 nov. 2013  ·  11Commentaires  ·  Source: rust-lang/rust

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)

A-ffi C-enhancement

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

Tous les 11 commentaires

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.

Cette page vous a été utile?
0 / 5 - 0 notes