Fix failing tests from the toml-test-harness

[zeenix]

#10 added tests to test the parser against the toml-test-harness suit. However, 210 tests currently fail and were ignored. The task would be to:

• fix them all and
• remove them from the ignore list.

[zeenix]

cc @CosmicHorrorDev

[CosmicHorrorDev]

I'd be willing to take a stab at getting basic quoted string parsing up to spec next

[zeenix]

I'd be willing to take a stab at getting basic quoted string parsing up to spec next

That's great but after working on #9, I realized that it would be probably best to take and adapt most of the parsing code from toml_edit crate. The parsing parts seems very standalone and don't drag in extra deps. That code already passes all the tests and will be a much faster way to get to resolve this issue.

[zeenix]

The parsing parts seems very standalone and don't drag in extra deps.

actually spoke too soon. :) Some of that code (especially the strings parser) is quite involved. So carry on please. If if you can learn from and/or take some of toml_edit code, that's not a problem still.

[CosmicHorrorDev]

I've also got a mostly spec compliant handwritten toml-parser (10 failing tests from toml-test) that may be a good more barebones reference, but ya I've also been referencing toml_edit too 😋

[CosmicHorrorDev]

Speaking of, I guess that we could lift that parser into here to further drop the number of dependencies, but there's definitely some cleanup that needs to happen first (particularly around the complete lack of error context)

[zeenix]

I've also got a mostly spec compliant handwritten toml-parser (10 failing tests from toml-test)

Nice. I'm glad you already know TOML so well (unlike me). :)

Speaking of, I guess that we could lift that parser into here to further drop the number of dependencies, but there's definitely some cleanup that needs to happen first (particularly around the complete lack of error context)

Hm.. while dropping our only mandatory dep does sound appealing, I think I'd rather want to continue with winnow since:

• It's a well-established crate for parsing and chances of projects already depending on it, are very high and so in many cases, it will not even count as as an additional dependency dragged in by this crate.
• It doesn't drag in other mandatory deps.
• any optimisations already in it and that will come in the future, will benefit us as well. We already benefit from its simd feature.