[pull] master from BurntSushi:master#4
Open
pull[bot] wants to merge 124 commits into
Open
Conversation
Support encoding and decoding json.Number
encoding/json encodes it as "", but IMHO that's confusing, and since it would generate invalid TOML before (`keyname =`) it's okay to change this to an error. Another alternative might be to skip the field if the return value is nil, but that's probably also a bit confusing in some cases, and we can change error to skip in the future and remain compatible, but we can't do the reverse.
A common use case for this is time.Time, which will get marshaled otherwise. A struct with private fields set is *not* considered to be "empty"; this is because some structs (such as time.Time) contain only private fields. Fixes #353
omitempty also considers structs with all zero values "empty".
…rs aren't
It would try to encode this:
arr = [{}, 0]
As:
[[arr]]
[[arr]]
Because it would only check the type of the first array entry. This made
sense before TOML 1.0 since all array entries had to be the same type,
but now we need to check all elements.
change eindirect behave match with indirect from decode
Don't panic with 'omitempty' and uncomparable type
…efore This is more compatible with the previous behaviour, as well as what stdlib does. Ref: #360
And add CI to test on i386.
Fix test on 32 bit arch
Would panic if the TOML had just one line without a newline at the end of the file.
Keys were marked as "Undecoded" in the meta when using UnmarshalTOML from the Unmarshaler interface. Unlike Primitive, I don't think this makes sense as UnmarshalTOML() explicitly "decodes" the value. Also mark all values below the table or array, and assume the parent UnmarshalTOML() handled this correctly. Fixes #425
Don't need the exception as my PR to improve it got merged.
I'm not entirely sure if I understand what's going on here, but this seems to fix it. Fixes #430
The map is in fieldsSub, so when iterating over fieldsDirect the length check would think it's "last" and won't write the comma, whereas on the second writeFields() call the test would fail and it would (wrongly) write the comma. So just sum the lengths. Fixes #438
This commit is a small followup for PR#426 to handle another case with the custom unmarshal. This was found in a complex TOML based image customization "blueprint".
Otherwise round-tripping something like 5e+22 won't work.
lexNumberOrDateStart() is only called from lexValue() on isDigit(r), so !isDigit(r) in there can never happen.
It has lx.skip(isWhitespace), so the isWhitespace(r) can never be true.
This doesn't really need tests IMO, but easy enough to write. The end goal is to have 100% test coverage at least for lex.go and parse.go, which is helpful for finding new test cases for toml-test.
Never referenced; not sure what it was used for in the past, but it's no longer.
Fixes: ./encode.go:231:11: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:233:11: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:282:10: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:284:10: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:286:10: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:300:11: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf ./encode.go:315:11: non-constant format string in call to (*github.com/BurntSushi/toml.Encoder).wf Fixes #445
No longer used since TOML 1.1
toml currently allows infinite table nesting; a document in the form "a.«10,000 more» = 1" takes ~2 seconds to parse and uses 1.8G of memory. I suppose we can may maybe improve on that a bit, but I haven't even looked. Just limit the table nesting to 128 by default, which should be more than enough for practically all real-world TOML documents.
fmt.Sprintf("%f", ...) pins six fractional digits and drops the
exponent, so what the unmarshaler actually sees is mangled: decoding
1e-10 into such a type yields "0.000000", which parses straight back to
zero. 3.141592653589793 arrives as "3.141593", and 1.5e300 balloons into
a ~300-digit integer string.
I spotted it reading the float handling alongside unifyString, which
already uses strconv.FormatFloat with 'g' and -1 precision, so the two
paths disagree on identical input.
strconv.FormatFloat(sdata, 'g', -1, 64) is the shortest form that
round-trips, matching unifyString and the encoder.
This is the only layer the conversion can be corrected at, since the
unmarshaler is given bytes rather than a float64 and a caller cannot
recover precision once we have already truncated it. Left as-is it is
silent data loss for any custom scalar type fed a TOML float, with small
magnitudes collapsing to zero being the worst of it; added a test
covering the precision, exponent and small-value cases.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )