Add ImportC compiler to dmd

[Adam D. Ruppe]

On Monday, 10 May 2021 at 00:47:08 UTC, 12345swordy wrote:
> The advantage of having this built into the compiler itself is 
> that you don't have to rely on a third party library for 
> importing c functions into your d code. Accessibility is the 
> key advantage here.

That could be easily done with the existing dpp approach. You 
could even just make dmd recognize the .dpp extension then shell 
out to dpp and users would never know.

Or heck even if the deimos repo was bundled with the download 
users would never know and it would work even better for a lot of 
cases.


Anyway, I wrote this on chat and was goinna clean up for my blog 
but I'll repeat it here instead:


my problems with dpp: 1) it is slow and always will be. it 
doesn't know what actually needs to be translated, so it just 
takes all the C and converts it to D and dumps it out. so dpp 
wastes time on huge amounts of useless work, then dmd wastes huge 
amounts of time sifting through it. I tried to optimize this by 
recognizing certain filename patterns and shifting it to imports, 
but it still has to do tons of work because of macros which 
brings me to:

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.

3) some C code is  still slightly different than D code and even 
with the help of an AST you can't fix all this up - again blame 
macros for much of it - meaning you can still generat crap
It is possible that a dmd-integrated solution can address some of 
this. It can just parse the C definitions and keep a table of 
them in memory instead of translating it to a file. It can keep a 
separate macro namespace and apply them in a semantically-aware 
fashion to avoid generating a bunch of that intermediate code. 
when it does apply a macro, it would take the D ast, to C String 
it, run the processor in a sandbox, C parse the result, then 
paste that into the  ast, limiting the pain.

But that's still not going to always work.

And a lot of those things use various compiler extensions and 
newer language features that dmc likely doesn't implement much 
of. Some require annoying #defines before #include and that's ... 
well possible but fairly tricky too, especially if it is trying 
to translate the declarations into the D module structure
so i think dmd integration is a better approach than dpp. but im 
a lil skeptical  if it will actually work as opposed to being 
some proof of concept dumped in and abandoned. The amount of work 
needed to bring this from proof of concept that sometimes works 
to actually usable thing that covers ground that the Deimos repo 
doesn't already have is going to be significant and probably 
better spent somewhere else.