Is importC ready?

[bachmeier]

On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas wrote:
> On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:
>> I tried to compile a simple C file this morning, containing
>>
>> ```
>> #include "nmath.h"
>>
>> double fsign(double x, double y)
>> {
>> #ifdef IEEE_754
>>     if (ISNAN(x) || ISNAN(y))
>> 	return x + y;
>> #endif
>>     return ((y >= 0) ? fabs(x) : -fabs(x));
>> }
>> ```
>>
>> I assumed this would be straightforward since it doesn't have 
>> a bunch of dependencies and it's only a few lines of code. 
>> Instead, I got a stream of errors. After running the file 
>> through the preprocessor, I had to comment out anything with
>>
>> -  `__extension__`
>> - Restricted pointers `*__restrict`
>> - `_Float128`
>> - `__asm__`
>>
>> And in the source, anything with ISNAN, or in the preprocessed 
>> file,
>>
>> - `__builtin_isnan`
>>
>> I [filed a 
>> bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
>> this experience, it's not obvious to me that importC is ready 
>> to be part of a stable compiler release. Maybe I just had bad 
>> luck with the choice of file.
>
> It looks like that file uses a lot of compiler extensions
>
> https://dlang.org/spec/importc.html#limitations
>
> ImportC only compiles standard C11 and nothing more
>
> (Although that noreturn part might need updating since we have 
> that now, i think)

It doesn't seem practical to ignore compiler extensions and leave 
them to the user to debug and fix. My understanding is that you 
can convert restricted pointers `*__restrict` to a simple `*` - 
the compiler should recognize that and make the change for you. 
At a minimum, the compiler knows when it's encountering 
extensions and can spit out a message telling you what's going 
on. The current messages are pretty awful.