Repository navigation
feat!: support spec v4.4 - #88
Conversation
|
Two things I checked that are worth recording, since neither is obvious from the diff. The encoder needed no change, and that's verifiable rather than assumed. v4.2 moved four encoder rules from SHOULD/MAY to MUST (§7.1 literal UTF-8 and lowercase hex, §7.2 must-not-over-quote, §7.3 keys must be unquoted when they match, §11.1 delimiter quoting widened to primitive list items and root primitives). Each one is pinned by an existing encode fixture and each passes, so the crate already conformed on all four.
I'd also suggest surfacing decoded as Two requests before merge, both tests rather than code:
Two small things, non-blocking: Also worth a line in the release notes: non-strict decoding of a wholly-indented document now yields Happy to approve once the tests land. |
|
Thanks for the thorough pass, and sorry for the silence. The branch has since gone on to spec v4.4, which settles most of it:
The |
|
One more commit on top: |
`deny_unknown_fields` guarded `TestOptions` but not `TestCase`, so every case-level field was dropped: `minSpecVersion` on 103 of 564 cases, `note` on 114, and `specSection` on all of them. A fixture tagged for a spec this crate has not implemented ran anyway, which is the situation the tag exists to report. Deny unknown fields on the case too, and fail with the version it needs when a case postdates the targeted spec. `specSection` and `note` now appear in the failure label, so a red case names the rule it broke.
|
Re-ran this at All three of your points hold up:
On the fixture tags: I took you at your word that Rather than hand it back to you I pushed
One judgement call worth your opinion: I made a too-new fixture fail rather than skip. For a downstream runner skipping is the point of the tag, but for the reference implementation I'd rather a submodule bump tell us the spec moved than quietly run fewer cases — especially with #75 adding a I tested both guards by mutation and reverted: injecting a Squashing and merging this now rather than holding it any longer. If you'd rather One for the release notes: non-strict decoding is meaningfully stricter than 0.6.1, rejecting malformed headers, row-width mismatches, trailing content and over-indented lines it previously recovered from. Worth saying plainly, since the commit subjects won't carry it. |
Brings the crate to spec v4.4 – the submodule moves to the v4.4.0 tag and every fixture passes. The branch first went through v4.2.1 and v4.3.0, and each behavior change is its own commit, so the history reads as a changelog.
The biggest change is non-strict decoding.
with_strict(false)now recovers from exactly the five conditions of §14.4 – a declared[N]is advisory, duplicate keys resolve last-write-wins, indentation may use tabs or uneven spaces, blank lines inside a header span are skipped, and a block whose first line starts too deep takes that depth. Everything else errors in both modes, including malformed headers, over-indented lines and row-width mismatches. Code that relied on non-strict mode to read sloppy input may now get an error. Documents a conforming encoder writes decode as before.Other behavior changes users may notice:
[comes before its first colon must be a valid header (strict mode no longer readsa[2:]{x}as a key), a hyphen marks a list item only at item depth and may be followed by several spaces, only SP and HTAB count as whitespace, a"opens a quoted span anywhere in a line, spaces between a quoted key and its colon are accepted, whitespace before a nested field group is an error, and a header whose length exceedsusizestill parses.float_roundtrip, so floats keep their exact value on the way to TOON.The "Documented implementation-defined behavior" list in
lib.rsno longer mentions tab indentation – §14.4 now defines it.