Nim: unicode.nim Error: type mismatch: got <seq[char]> but expected 'string'

[yglukhov]

Happens with --os:standalone --gc:none flags.

# test.nim
import unicode

# panicoverride.nim
proc rawoutput(s: string) = discard
proc panic(s: string) = rawoutput(s)



md5-8a2a07e48deb5e35b7caf3f6f31b3042



nim c --os:standalone --gc:none test.nim



md5-8a2a07e48deb5e35b7caf3f6f31b3042



Hint: used config file '/home/yglukhov/Projects/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: test [Processing]
Hint: unicode [Processing]
Projects/nim/lib/pure/unicode.nim(255, 3) Error: type mismatch: got <seq[char]> but expected 'string'

[AchalaSB]

Is there any way to fix this ?

[deech]

I wanted to take a stab at this issue to get my feet wet with the Nim codebase.

The reason this compiler error is occurring is that when --gc:none is passed in string slice operations in unicode.nim resolve to the openarray implementation of slicing which returns a seq[char]. The typechecker cannot unify seq[char] with string and fails.

I had a hard time figuring out why string was being coerced openarray but it seems to be happening in sigmatch.nim.

So I have some idea why this issue is happening but no idea how to go about fixing it so if someone can offer some guidance I'm happy to work on a PR.

[exelotl]

Hey, has anyone made any progress with this? It's rendering large portions of the standard library unusable for embedded programming, when they really should be usable 😅

[Araq]

Don't use --os:standalone --gc:none, use instead --os:standalone --gc:regions or whatever. Embedded programming has nothing to do with gc:none (which is misdesigned and needs to die).

[exelotl]

@Araq Currently --gc:none is the only option that works for me, because every other GC option results in large quantities of TNimNode being created in stdlib_system.c (even when my source program is totally empty).

I'm dealing with just 32k RAM. Under --gc:regions my program won't even link because the toolchain recognises that its static memory requirements would be too high.

Should I file an issue for this? Or am I missing some option that would fix everything?

[edit: another issue is, the heap alone is enough to make it unviable, it statically reserves a whopping 33mb! I don't even want a heap!]

[Araq]

Yup, these should be optimized out.