-
-
Notifications
You must be signed in to change notification settings - Fork 530
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
Encoder reorders elements, causing incorrect encoding. #43
Comments
Yikes. Reproduced. Working on a fix. |
All set. I included your code as a regression test. Thank you! |
BurntSushi
added a commit
that referenced
this issue
Jun 11, 2014
Thank you for the prompt fix. You're doing an excellent job maintaining this library :) |
Thanks! :) |
mitszo
pushed a commit
to accense/toml
that referenced
this issue
Jul 19, 2016
Array hashes were being considered as normal keys rather than hashes, which sometimes caused them to come before other keys and therefore producing incorrect TOML. This was fixed by being a bit cleaner with type handling. Now tomlTypeOfGo is a single point of truth about finding the TOML type of a Go value. This includes a regression test from BurntSushi#43.
mitszo
pushed a commit
to accense/toml
that referenced
this issue
Jul 19, 2016
This was actually fixed in commit 44d4af for BurntSushi#43, but this adds a regression test from BurntSushi#42.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected: toml package to encode data properly.
Actual: During encoding it seems like arrays of maps are given some sort of priority, the ordering of the fields is mixed up, and an incorrect toml representation of the object is output.
Given the following reproduce code:
The expected output of this is:
But the actual output is:
Because of the ordering of the fields, the field "zero" belongs to the [[map.maparr]] entry rather to the [map] entry, meaning that the encoded toml is incorrect.
The text was updated successfully, but these errors were encountered: