https://issues.dlang.org/show_bug.cgi?id=24374

dave287091@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86                         |All
                 OS|Mac OS X                    |All
           Severity|enhancement                 |normal

--

https://issues.dlang.org/show_bug.cgi?id=24374

Derek Fawcus <dfawcus+dlang@employees.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfawcus+dlang@employees.org

--- Comment #1 from Derek Fawcus <dfawcus+dlang@employees.org> ---
I just ran in to exactly this issue while evaluating the potential for adding D (betterC mode) code to an existing C project, as an alternative to adding Rust code.

For that I needed to be able to annotate existing functions with @nogc and nothrow, however the basic import of a C file does not allow for this.

As such I decided to generate a .di file using this mechanism, and manipulate the file, prepending the annotations.  Then I ran in to this issue.

While I could work around this by altering my source files adding tags such that the struct / union is no longer anonymous, that is not viable.  One reason being the quantity of changes required.

More significantly the project headers in question transitively included system headers (inttypes.h) which themselves resulted in the same problem, as those system headers had similar anonymous structs and unions.  Having to edit these is a non starter.

There was another reason for wishing to pre-process the C headers to .di files, that being efficiency.  By doing so, it would avoid the D compiler from having to repeatedly parse/transform the complete C sources, making builds faster.

As it stands, the lack of ability to control the annotation (@nogc, nothrow, etc) applied to C sources so imported rather makes the use of ImportC and BetterC as I envisaged impractical.

--

https://issues.dlang.org/show_bug.cgi?id=24374

--- Comment #2 from Derek Fawcus <dfawcus+dlang@employees.org> ---
I should modify that comment, I see that I can work with betterC despite the inability to mark the C imports as @nogc etc, as long as I haven't marked the betterC code in that fashion.

So that was an error on my behalf, and I can continue investigating the viability of betterC additions to existing C code.

I suspect this means not being able to optimise the repeated import of a common C header/module across multiple betterC file, in that each will have to parse the C source each time.

--