feat(toml): TOML 1.1 parse support

[epage]

What does this PR try to resolve?

Support

• multi-line inline tables
• trailing commas on inline tables
• \e string escape character
• \xHH string escape character
• Optional seconds in times (sets to 0)

Anyone using these features will raise their development MSRV. The published Cargo.toml file will still be compatible with old TOML parsers and so old Cargos. If toml_datetime gains the ability to track whether seconds were optional (will be a breaking change), then that might change though that would only apply to package.metadata as we don't make use of times in Cargo.

How to test and review this PR?

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

Thanks for the upgrade. I am really excited about it!

Anyone using these features will raise their development MSRV.

Do we care about helping people catch this? Like we discussed earlier on Zulip, one (and probably the only) case that may affect people is via git dependencies.

[epage]

If people have an MSRV, they should generally have CI jobs to verify it or else it is likely a lie. We call out verification as an expectation.

To verify this, we'd have to write a custom tool that re-parses the file and try to walk the structure for inline tables and check for these. It won't be cheap.

[weihanglo]

To verify this, we'd have to write a custom tool that re-parses the file and try to walk the structure for inline tables and check for these. It won't be cheap.

A way to do it is that we depend on an old version of toml_edit for 1.0 spec, and parse again to see if it fails.

If people have an MSRV, they should generally have CI jobs to verify it or else it is likely a lie. We call out verification as an expectation.

I agree, though not everything is in a ideal state having a proper CI setup. If not code change, I guess it is worth putting a caution in CHANGELOG for this MSRV breakage.

[weihanglo]

Thanks!

View changes since this review

[weihanglo]

@rfcbot fcp merge T-cargo

This a one-way door change — Once Cargo starts supporting 1.1 we cannot revert back. Worth a check with the entire team.

[rust-rfcbot]

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

• @0xPoe
• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[0xPoe]

A dumb question: Does it make sense to add some tests to cover the newly supported formats and parsing behavior in Cargo? or is this outside the scope of Cargo tests? (The toml itself would have sufficient tests, and there is nothing special here.)

View changes since this review

[epage]

I think it's fine to delegate that to toml which includes running the TOML conformance tests.

[0xPoe]

Thanks!

View changes since this review

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔