tomland

tomland copied to clipboard

I realized this issue working on #128 and I have discussed in with @willbasky in private. Basically tests like these:

it "can parse true" $ parseX boolP "trueXXX" True

pass, and it confused me for a bit, but then I realized that it's fine, that's how parsers work. You might say that testing boolP <* eol instead of boolP would be better, but it's not a big problem.

Instead, what is a problem is that we are wrapping most parsers with lexeme which allows for any space characters and comments, but also accepts 0 spaces.

That means a = true \n XXX = 1 is a valid TOML, but so is a = trueXXX = 1, which is bad in my opinion. Also, a = trueXXX would also be valid TOML since the last XXX is simply ignored (this is easily fixed by adding a eol in tomlP though). In other words, the current parser accepts all valid .toml files, but also accepts wrong ones.

This could probably be fixed by making sure that every value is followed by a space, an EOL or one of these: ,]}. It would be a bit less performant but we can run benchmarks now.

@jiegillet This is indeed an issue. I guess what we can do is to have two combinators:

lexeme
lexemeNoLn

And use lexemeNoLn explicitly in places with eol combinator to check on end of line. I don't think this will make parsing noticeably slower. But this should be addressed in some future.