[SAoC] 'DPP with Linux kernel headers' Project Thread

[Cristian Becerescu]

Update for week 1 of Milestone 3

(1) I've identified the actual cause for a previous issue and 
also implemented a solution for it:

> ---(Maybe) Bug #6---
> Error: undefined identifier xattr_handler
>
> The above happens in a struct declaration (a field of that type 
> is declared) and also in a function declaration (a parameter of 
> that type). The struct declaration for xattr_handler is not in 
> the generated D file. Will look more into this.

The problem there was that we would have something like this:

void f(struct A**); // C code; A is undeclared

and, because A is undeclared, DPP should generate an plain 
'struct A;'. It turns out that previously, DPP was only looking 
at the cursor type for the first pointee of 'struct A**', which 
was 'struct A*' (which is not a Record type). So DPP would not 
generate the corresponding plain struct.

The solution is simply moving on the pointee type until the 
cursor type is not a Pointer type (so eventually we would get to 
the Record type in the case above).

PR: https://github.com/atilaneves/dpp/pull/218


(2) Found another bug, this time about bitfields. A succinct 
explanation and a small example can be found here: 
https://gist.github.com/cbecerescu/29188e4c0f0bb83e0e85e4e0dccc8c30


(3) I've tried using DPP with other kernel headers as well 
(specifically netdevice.h), and usually I get an error telling me 
the resources have been exhausted.

My guess is that the issue is the 'lines' array, which contains 
all of the lines to be written in the generated D file. As far as 
I know, we don't flush at any point during this process. I assume 
this array gets very large at some point (I've seen a maximum of 
~100K generated D files so far, although other factors could be 
also impactful, maybe the AST).

I thought of two approaches here: either try to write to the file 
when 'lines' gets too big, or translate each C header into 
different D modules. I'm still open to suggestions.

(4) I still have not got to the cause of this (I assume it's a 
sort of redirection of stderr, but I can't reproduce it with any 
warnings I tried):

> ---Bug #3---
> In some cases, dpp writes a clang warning into the generated D 
> file. For example > (for virtio.h):
>
>foo.d.tmp:81822:141: warning: __VA_ARGS__ can only appear in the 
>expansion of a C99 variadic macro #define __PVOP_VCALL ( op , 
>pre , post, ... ) ____PVOP_VCALL ( op , CLBR_ANY , 
>PVOP_VCALL_CLOBBERS , VEXTRA_CLOBBERS , pre, post , ## 
>__VA_ARGS__ ).
>
> This is written exactly as is in the D file. I still have to 
> figure why this happens.