[SAOC 2026] ImportC Weekly Update #4

Niyati Jain niyati.jainn15 at gmail.com
Wed Oct 14 13:28:47 UTC 2026


**SAOC 2026: ImportC Weekly Update #4 : Milestone 1 Wraps Up**

This week brings Milestone 1 to a close.
This week I closed out what was left from last week's sljit 
codegen bug, then moved into dmd compiler work, fix for the 
union-compatibility issue, a genuinely useful back-and-forth 
review with my mentor on it, and triaging another bug he flagged.

**Closing out last week:** filed the test21 
stack-overflow/access-violation bug from sljit's suite upstream 
against dmd 
([#24028](https://github.com/dlang/dmd/issues/24028)), with the 
full standalone repro, build command, and cdb output.
- Got the sljit package published on the DUB registry as v0.1.0 
([niy-ati/sljit](https://github.com/niy-ati/sljit), [on 
DUB](https://code.dlang.org/packages/sljit)).

**The main thread this week was #21891**, two unions sharing a 
name across different C files currently have to match field for 
field, in order, when really only size and alignment should 
matter, since a union has no member order to disagree on. I 
implemented exactly that and tested it against the real 
`sljitMain.c`/`sljitTest.c` mismatch, which is the actual 
motivating case behind 
[#21891](https://github.com/dlang/dmd/issues/21891).

It fixed the type-merge error, but testing against the unmodified 
files surfaced what the simplified test missed: once two 
differently-shaped unions are accepted as compatible, dmd keeps 
whichever declaration it saw first and drops the other's fields, 
so code in the file that declared the dropped fields breaks 
instead. Reported that back with the actual repro and tried a 
refinement next, that required one side's fields to be a literal 
subset of the other's by name and type, but that doesn't cover 
the real sljit case either i.e the two files' fields genuinely 
don't overlap by name (one has a field called `func`, the other 
has `func0` through `func3`).
- Opened PR [#24043](https://github.com/dlang/dmd/pull/24043) 
with both a positive regression test and a fail_compilation 
negative test.

**Status:**
- PR for #21891: https://github.com/dlang/dmd/pull/24043
- Stack-overflow bug: https://github.com/dlang/dmd/issues/24028
- sljit on DUB: https://code.dlang.org/packages/sljit
- sljit package repo: https://github.com/niy-ati/sljit
- importC repo: https://github.com/niy-ati/importC

**Milestone 1 status, wrapping up:** the CI matrix, #21890, 
#20407, filing new bugs, and the DUB publish are all done. Fix 
for #21891 is in review as PR #24043. The sljit package itself is 
done and working. The full 138-test upstream suite still can't 
run completely unmodified, that's purely blocked on a dmd codegen 
bug ([#24028](https://github.com/dlang/dmd/issues/24028)), not 
anything in the package. Once dmd resolves it upstream, the suite 
should just pass, with nothing further to build or change here.

Genuinely good milestone to close out, it started with two named 
parser bugs, and now ended up finding a real compiler codegen bug 
that wasn't known earlier, and reopened a design question on 
union compatibility.

**Next week:** start Milestone 2 with `sqlite`, since `zlib` 
already compiles clean on both platforms from the Milestone 1 CI 
matrix.
First concrete step is the Windows static-initializer issue, 
which isn't filed yet.
See the full Milestone 2 scope here: 
https://gist.github.com/niy-ati/9d2c587a818711f3fc2f59e962d50ebc

Thanks to Nicholas for the constant guidance throughout. Feel 
free to leave any feedback, questions, or suggestions.


Regards,
Niyati



More information about the Digitalmars-d mailing list