Closed timotheecour closed 1 year ago
The cause of this is the keyCache which seems to be broken at compile time.
The quick rundown is: When name1
is encountered, a scalar event is created. However, before it is emitted, the parser checks whether a :
follows – if so, name1
starts a map. The created scalar event is pushed into the keyCache and a mapping start event is created and emitted. When querying the next event, the parser retrieves the scalar event from the keyCache.
However, at compile time, when the mapping start is generated, this seems to also update the pushed event in the key cache (which it shouldn't!). This is a VM bug. This is the parser code where it occurs.
This explains the difference in the output you showed in your comment on the other issue: Instead of the first key of the map, you get another +MAP
.
Is this enough info to fix it in the VM? I can try writing up a minimal example to file a Nim bug, but I am afraid the time slot I allocated for rewriting the NimYAML parser has expired and I don't have much time pushing this forward so things will take more time.
@flyx after a painful reduction I've found the root causes:
Compile time loading now works well enough. The linked Nim issue should be re-evaluated as I don't see the problem occurring with NimYAML anymore.
Dumping doesn't work but I think that's not a priority. Some other things don't work at CT:
Apart from that, all loading tests for loading into native types succeed at comptime, which is good enough for me to close this and the other issue.
example 1: works at RT(?), fails at CT
wrote works at RT with a
?
because I'm not sure whether the output (A,
) is correct or not.RT: prints:
CT (uncomment static: main()): (with https://github.com/nim-lang/Nim/pull/15947) errors:
example 2: works at RT and CT
adding
{}
makes it workexample 3: works at RT and CT