Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
yglukhov opened this issue Nov 20, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@yglukhov
Copy link
Member

commented Nov 20, 2018

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

# test.nim
import unicode
# panicoverride.nim
proc rawoutput(s: string) = discard
proc panic(s: string) = rawoutput(s)
nim c --os:standalone --gc:none test.nim
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

This comment has been minimized.

Copy link

commented Nov 21, 2018

Is there any way to fix this ?

@deech

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2018

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

This comment has been minimized.

Copy link

commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 21, 2019

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

This comment has been minimized.

Copy link

commented Jan 21, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jan 22, 2019

Yup, these should be optimized out.

yglukhov added a commit to yglukhov/Nim that referenced this issue May 21, 2019

yglukhov added a commit to yglukhov/Nim that referenced this issue May 29, 2019

@Araq Araq closed this in 6904f32 May 29, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.