[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