Lots of people are trying out ImportC, which is good news! Lots of people encounter a problem here and there with a strange error message emanating from the compiler when compiling a .h file.

A good way to find out what is causing this error message is to run the C preprocessor (such as cpp) over the .c file that #include's it, and direct the result into a .i file.

A bit more work, and usually the offending line in the .i file is isolated.

A large number of these errors result from the .h file making use of some bizzaro C language extension, that nobody who makes these .h files seems to be able to resist.

It is not practical for ImportC to implement every C compiler's nutburger extension. But usually there is a way to write a C macro to provide a workaround.

This is the job of druntime/src/importc.h, which is automatically #include'd by ImportC:

https://github.com/dlang/dmd/blob/master/druntime/src/importc.h

To fix the problem you've encountered, adding a macro to importc.h can get your code moving again (and please file a bugzilla or a PR so everyone can take advantage of your findings!).

Another file used to compensate for nutburger C compiler extensions is __builtins.di:

https://github.com/dlang/dmd/blob/master/druntime/src/__builtins.di

which, having access to D's constructions, can often fake a C compiler extension. __builtins.di is also automatically imported by every compilation of an ImportC C file.

On Sunday, 3 September 2023 at 08:55:13 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/blob/master/druntime/src/importc.h
>
> To fix the problem you've encountered, adding a macro to importc.h can get your code moving again (and please file a bugzilla or a PR so everyone can take advantage of your findings!).
>
> Another file used to compensate for nutburger C compiler extensions is __builtins.di:
>
> https://github.com/dlang/dmd/blob/master/druntime/src/__builtins.di
>
> which, having access to D's constructions, can often fake a C compiler extension. __builtins.di is also automatically imported by every compilation of an ImportC C file.

importc.h is how I nullified MSFT's idiotic #define based metadata annotations that liter all of their header files while at DConf. One small step closer to jettisoning the hopelessly outdated MinGW header translations from the Windows XP era...

It Works.

On 9/9/2023 7:19 PM, Adam Wilson wrote:
> importc.h is how I nullified MSFT's idiotic #define based metadata annotations that liter all of their header files while at DConf. One small step closer to jettisoning the hopelessly outdated MinGW header translations from the Windows XP era...
> 
> It Works.

I hope you did a PR for it!

Microsoft headers also include inline assembly with no way to turn it off. Sigh. I was forced to try supporting their inline assembler.

On Monday, 11 September 2023 at 01:30:16 UTC, Walter Bright wrote:
> On 9/9/2023 7:19 PM, Adam Wilson wrote:
>> importc.h is how I nullified MSFT's idiotic #define based metadata annotations that liter all of their header files while at DConf. One small step closer to jettisoning the hopelessly outdated MinGW header translations from the Windows XP era...
>> 
>> It Works.
>
> I hope you did a PR for it!
>
> Microsoft headers also include inline assembly with no way to turn it off. Sigh. I was forced to try supporting their inline assembler.

Merged it at DConf. No more SAL nonsense from MSFT headers. Ever.

Microsoft headers are full of aggravation. Speaking of, have you had a chance to look at this aggravation yet? https://issues.dlang.org/show_bug.cgi?id=24132

I also have this one open: https://issues.dlang.org/show_bug.cgi?id=24121
Making ImportC work with DI files can offer us a potential fast-path to automated binding generation directly from the compiler. It'll take more work to make this work with the MSFT headers, but once we do, we could theoretically replace that giant pile of nastiness that are the MinGW translations with a nice, clean ImportC auto-generated files that are much easier to keep synchronized with the canonical Windows SDK headers.

On Monday, 11 September 2023 at 03:44:20 UTC, Adam Wilson wrote:
> Making ImportC work with DI files can offer us a potential fast-path to automated binding generation directly from the compiler

We also already have automated bindings from the projections thing microsoft put out

https://github.com/microsoft/win32metadata/tree/main

D - https://github.com/rumbu13/windows-d (Community)

On 9/11/2023 5:30 AM, Adam D Ruppe wrote:
> On Monday, 11 September 2023 at 03:44:20 UTC, Adam Wilson wrote:
>> Making ImportC work with DI files can offer us a potential fast-path to automated binding generation directly from the compiler
> 
> We also already have automated bindings from the projections thing microsoft put out
> 
> https://github.com/microsoft/win32metadata/tree/main
> 
> D - https://github.com/rumbu13/windows-d (Community)

I didn't know that existed. Nice! Are you using it?

On 9/11/2023 11:32 AM, Walter Bright wrote:
>> We also already have automated bindings from the projections thing microsoft put out


This should work for ImportC C files that use it. However, if ImportC is used on an existing project, it'll expect the Windows .h files to work. I doubt we'll ever get them to work perfectly with all the wacky idiosyncrasies in them, but we'll do what we can.

On Monday, 11 September 2023 at 18:32:15 UTC, Walter Bright wrote:
> I didn't know that existed. Nice! Are you using it?

No, I find the existing druntime ones to work well and supplement with with private extern(C) decls when I have to.

I just don't want people to forget that thing exists.