Is importC ready?

[bachmeier]

On Tuesday, 9 November 2021 at 19:04:04 UTC, Dave P. wrote:
> On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:
>> 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
>>>> [...]
>> 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.
>
> ImportC understands `restrict`, it just doesn’t understand 
> non-standard keywords. See 
> [this](https://dlang.org/spec/importc.html#wrapping).
>
> That example is incomplete, but you can  `#define __restrict 
> restrict`, `#define __asm__ asm`, etc.
>
> I agree that the error messages suck.

Yeah, I saw that example, but the main limitation of such a 
strategy is that I don't have the knowledge to construct a file 
that without potentially changing behavior. I made some changes 
by hand and confirmed that changing `*__restrict` to `*restrict`, 
`__asm__` to `asm`, and `buitin_isnan` to `isnan` results in a 
file that compiles. That still leaves `_Float128`. This all 
requires a lot of C compiler knowledge that shouldn't be required 
of a D programmer.