Make shared static this() encoding table compilable

[bauss]

On Monday, 14 March 2022 at 09:40:00 UTC, zhad3 wrote:
> Hey everyone, I am in need of some help. I have written this 
> Windows CP949 encoding table 
> https://github.com/zhad3/zencoding/blob/main/windows949/source/zencoding/windows949/table.d which is used to convert CP949 to UTF-16.
>
> After some research about how to initialize immutable 
> associative arrays people suggested using `shared static 
> this()`. So far this worked for me, but I recently discovered 
> that DMD cannot compile this in release mode with optimizations.
>
> `dub build --build=release`  or `dmd` with `-release -O` fails:
>
> ```
> code      windows949
> function  
> zencoding.windows949.fromWindows949!(immutable(ubyte)[]).fromWindows949
> code      table
> function  zencoding.windows949.table._sharedStaticCtor_L29_C1
> dmd failed with exit code -11.
> ```
>
> I usually compile my projects using LDC where this works fine, 
> but I don't want to force others to use LDC because of this one 
> problem.
>
> Hence I'd like to ask on how to change the code so that it 
> compiles on DMD in release mode (with optimizations). I thought 
> about having a computational algorithm instead of an encoding 
> table but sadly I could not find any references in that regard. 
> Apparently encoding tables seem to be the standard.

I think it's a memory issue and it's unlikely to be solved.

I saw a similar issue a while ago where it worked with everything 
but DMD.

Someone can correct me but if I remember correctly it's because 
DMD issues instructions for each value (or something like that) 
in the static array and thus runs out of memory before any 
optimization can happen or whatever, but LDC etc. doesn't have 
said issue.

I can't exactly remember how it is, but I think it's something 
along those lines.

I don't think there really is a workaround as of now and probably 
never will be.