Add ImportC compiler to dmd

[Walter Bright]

On 5/11/2021 9:57 AM, IGotD- wrote:
> Adding a C compiler into the D compiler will increase the maintenance work load 
> and open up for new interesting bugs.

True enough. But *any* method of automatically importing/translating C code will 
have the same problem.


> I also find this a bit strange coming from a person that thinks making GC 
> pointers an own type would increase the complexity of the compiler, then 
> suddenly wants to add a complete C compiler into the D compiler.

ImportC is designed to be a "bag on the side" of dmd specifically to reduce 
complexity.


> Also the question raises what will be supported and what will not. There are a 
> lot of header files out there that are a mix between C and C++. Adding importing 
> C++ is difficult and the scope what is supported must be limited. This means 
> that a lot of header files will not work directly. C++11 and beyond with 
> templates, just forget it.

I can answer that question: no support for C++!


> I understand that importC would greatly make FFI easier but I think this is 
> easier said than done. It is definitely not worth making the D compiler into a 
> Frankensteins monster. I would go the conversion tool (that converts C header 
> files to D files) route in order to decouple a foreign language to the D language.

ImportC essentially does convert C files to D files, as its output is a D AST. 
The only way to make any C to D converter is to compile C to an AST, then 
convert the AST to D. If libclang was used, the exact same thing happens, except 
libclang hands you a C AST. We (as dpp does) still have to convert the AST.

Attempting to convert C to D using a text macro processor or string matching or 
some such is doomed to a terrible fate.