Starting to implement the early Cbindgen and C to Thrust transpiler in Thrust v0.3.0

[StevensBenavides]

Hi everyone,

I'd like to open a discussion about how Thrust should work with C code. Right now there are really two different needs hiding under the same idea, and I think we'll get a better result if we treat them as two separate features.

1. importC "header.h"; (language feature)

The goal is simple: you should be able to use a C library from Thrust without writing the bindings by hand. Since it's part of the language syntax, it shouldn't need a flag. It would just run as part of the normal compile.

The idea is to read the header with libclang (through Rust's clang crate) and generate the matching Thrust declarations before semantic analysis. It would cover functions, structs, enums, typedefs, simple constants, and simple macros, and it would add @extern("...") and @convention("C") automatically. It wouldn't try to translate function bodies or inline assembly.

As an optional extra, --emit-c-bindings-thrust would save those generated bindings to a .thrust file. That's useful for debugging, caching, checking what was generated, or distributing the bindings.

2. --translate-c-to-thrust file.c (separate tool)

This is a different job: converting full C source files into Thrust code. I'd start with a small, well-tested subset of C and grow it over time.

Where I'd start

I think the first priority is making importC reliable:

Keep the header path in the AST.
Add a dedicated thrustc_c_import_synthesis layer.
Plug it in before semantic analysis.
Cover it in the main tests/ suite.

For testing, each new test folder or feature area should have at least 10 tests, covering successes, diagnostics, failures, and the generated output wherever code is produced.