Hello D community,

The past week, I worked on fixing compilation failures in importC involving struct delegated initializer.

struct Foo {
    int x;
    int y;
};

struct Bar {
    struct Foo f;
};

struct Bar b = {.f.x = 3}; // Error: only 1 designator currently allowed for C struct field initializer
struct Bar b2 = {
    .f.x = 3, // Error: only 1 designator currently allowed for C struct field initializer
    .f.y = 4,
};

Issue report: https://issues.dlang.org/show_bug.cgi?id=23374

I researched into this issue and implemented a fix to it and has been successfully merged.

Link to PR: https://github.com/dlang/dmd/pull/21883#event-19812674196

Now, that importC code compiles fine and also has been tested.

Additionally, I came across some inconsistencies in the dlang spec on importC enum. it strictly indicated that enum expressions are typed as 'int'. and some of the examples in the language spec was not also correct. I submitted a fix to it which has also been merged.
PR: https://github.com/dlang/dlang.org/pull/4317#event-19832789696

In the next week, I will be working on fixing issues involving taking the address of compound literals.

On Monday, 22 September 2025 at 13:02:45 UTC, Emmanuel wrote:

That's a great start into the SAOC program! Good luck with the rest!

On Monday, 22 September 2025 at 13:02:45 UTC, Emmanuel wrote:

Nice!!

On Monday, 22 September 2025 at 13:02:45 UTC, Emmanuel wrote:

Thanks for working on import C.

I feel like I would be remiss if I didn't mention the prior controversy about getting importC to recognize .i and .c files [1]. Not that I want to derail your plans for the SAOC...

Anyway, the suggestion from Steve was [2] was to have a separate "-CI" compiler flag to let the compiler know there is a separate path for C imports. The thread suggested that Walter might be sympathetic to this approach, but he also suggested an approach of putting the file on the command line directly [3], which Ian argued would cause duplicate symbol issues [4]. But I don't think anyone really came up with an objection to Steve's recommendation.

I think the main requirement coming from the GCC maintainers is that whatever is done cannot break GCC (or separate compilation).

Is resolving this issue something that can potentially get attention? It would make working with importC more seamless.

[1] https://github.com/dlang/dmd/issues/20184

[2] https://github.com/dlang/dmd/pull/14864#issuecomment-1430650577

[3] https://github.com/dlang/dmd/pull/14864#issuecomment-1432668054

[4] https://github.com/dlang/dmd/pull/14864#issuecomment-1434341040

On Tuesday, 23 September 2025 at 12:34:46 UTC, jmh530 wrote:

.h files are now recognized. And most of the issues that were plaguing importc file lookups are resolved.

I think we should let the next release get some use before deciding to add more switches.

-Steve

On Tuesday, 23 September 2025 at 12:41:36 UTC, Steven Schveighoffer wrote:

Really? That's great news. I was not aware of this.

I checked the nightly change log (https://dlang.org/changelog/pending.html) before posting but I hadn't seen anything. After some searching on Github, I found this
https://github.com/dlang/dmd/pull/21692

When I searched the change log for 20184, then there was an entry for "String maxsplit", but this hasn't had any activity since December 2024, which was several months before the most recent release. And it looks like this activity was just the comment about the issue getting moved. Before that the last activity was 2019. It looks like the github issues have different numbers than the bugzilla ones. Maybe something funky going on here with how the change log is generated.

On Tuesday, 23 September 2025 at 14:23:48 UTC, jmh530 wrote:

Looks like all sorted out ???

On Wednesday, 24 September 2025 at 06:44:46 UTC, Emmanuel wrote:

Way I understand it. Changelog needs to get sorted out though.

On Tuesday, 23 September 2025 at 14:23:48 UTC, jmh530 wrote:

The issue you linked was actually closed on August 13.

As I understand it, the automation of generating the changelog regarding issues closed is broken since we switched to github issues. So the release manager has to manually fix the changelog on release currently. I bet any automated pre-release changelog is going to be garbage.

-Steve