fix: reject trailing scalar in block mapping at end of document

[mvanhorn]

Summary

When the scanner sees a plain scalar in block context it speculatively pushes a KEY token with status UNVERIFIED (Scanner::InsertPotentialSimpleKey in src/simplekey.cpp) and only validates it when a later : triggers VerifySimpleKey. At end of stream (and at doc start/end and directives), Scanner::PopAllSimpleKeys pops the pending simple keys WITHOUT calling Invalidate(), so the still-UNVERIFIED KEY token survives in the token queue and the parser treats the dangling scalar as a valid key with a null value. The fix is to invalidate unverified pending simple keys in PopAllSimpleKeys (src/simplekey.cpp) before popping, so the leftover KEY token is discarded; SingleDocParser::HandleBlockMap then sees a bare SCALAR token where it expects KEY/VALUE/BLOCK_MAP_END and throws ParserException END_OF_MAP, matching the behavior already seen when a comment follows.

Why this matters

Parsing the document foo: bar followed by a bare line not-a-key (with no colon) at the end of the document succeeds, treating not-a-key as a map key with a null value, when it should be a parse error. If anything follows the dangling scalar (for example a comment), a ParserException "end of map not found" is correctly thrown, so the bug only manifests when the dangling scalar is the last content before end of stream. A collaborator (SGSSGene) confirmed on 2026-04-26 that this is a bug that must be fixed. The issue is labeled bug and help wanted, is unassigned, and has no PRs referencing it.

See #819.

Testing

• Happy path: foo: bar alone still parses to a one-entry map; foo: bar\nbaz: qux parses to a two-entry map (verified keys unaffected). - Bug case: ---\nfoo: bar\nnot-a-key\n at end of document now throws ParserException (end of map not found) instead of silently producing a null-valued key. - Existing error path unchanged: ---\nfoo: bar\nnot-a-key\n# A comment still throws ParserException at line 3, column 1. - Edge cases: dangling scalar as the only document content (not-a-key with no prior map) still parses as a plain scalar document; explicit-key form `?

Fixes #819

[jbeder]

[mvanhorn]

Addressed in 52e60b9 - the case from your screenshot now parses/rejects correctly. Full CTest suite passes locally.

[SGSSGene]

I am a little lost. What are you trying to say?

I should have looked at the changes.....It is finest AI slop :/ same as #1460 , uff what a waste of time.

[jbeder]

Heh yeah, you can tell from the format of this PR. Just the headers give it away.

[mvanhorn]

Fair call, and I'm sorry for the time it cost you both. These were AI-assisted and I should have reviewed and reshaped them much more carefully before submitting - the formatting tell is on me. If the underlying bugs are still worth fixing I'm happy to redo this as a minimal, hand-reviewed patch; otherwise I'll close both this and #1460. I'll hold off on anything further here unless it's genuinely ready.

[jbeder]

Dude...

[mvanhorn]

Yeah, that's fair. Closing both.