Add ImportC compiler to dmd

[Steven Schveighoffer]

On 5/9/21 8:55 PM, Adam D. Ruppe wrote:
> 2) preprocessor macros are bad and should be kept far away from D code. 
> but since C headers often define them you're thrust into this hell. dpp 
> makes it worse though because of its translation model - it has no 
> semantic awareness of actual need. so it ends up doing silly things like 
> turning import core.sys.linux to import core.sys.1. These tend to be 
> fixed with some ad-hoc #undef at the end of the translated section, or 
> sometimes translating certain macro patterns into superior D patterns, 
> adn enough work toward that will prolly achieve like 95% goodness. but 
> there's still bound to be some case that got missed no matter what.

I had this idea: what if in D code, you can access CPP macros 
explicitly. Like:

#CMACRO(<macro expression)

Which then you can use by running a specialized c preprocessor on your d 
code. C macros can only be defined in C header files, and if you choose 
to accept the above ugliness, then it properly translates that part to 
what the c preprocessor spits out. If the C preprocessor is not enabled 
(the default option), the macro call is an error.

This gives you the possibility to use C headers directly, doesn't 
interfere with normal D code, and also encourages you to find better 
ways to do the macro-y things if possible to get rid of the ugliness.

Another option is to allow CPP macros with a pragma scope:

pragma(cmacro, on);
pragma(cmacro, off);

Which might hide some of the ugliness, but still is opt-in for using macros.

-Steve