Repository navigation
Test duplicate key namespaces #575
Description
Problem
Library keeps entries and @string definitions in separate key namespaces, but the test suite currently exercises strict duplicate handling only for entries. That leaves two related contracts implicit:
- duplicate
@stringkeys must fail under the default strict policy; and - an entry and an
@stringdefinition may legitimately share the same key.
Without explicit coverage, a future change to duplicate detection could either admit duplicate string definitions or incorrectly treat different block types as conflicts.
Proposed coverage
Add focused library tests that verify strict duplicate rejection for String blocks and verify that entry and string keys remain independent namespaces. No production behavior needs to change.
Activity
claell commentedon Jul 16, 2026
A focused test-only implementation is available in draft PR #576: #576
MiWeiss commentedon Sep 2, 2026
Hi @claell — I'm posting this same note on all of your July 16 issues and PRs (#567–#597), so apologies for the form-letter feel.
I'm closing this. The batch — 13 issues, 18 PRs, ~3,000 lines, opened within a two-hour window with spec-style language and forward-references to PR numbers that didn't exist yet — reads as AI-generated rather than something you hit and verified by hand. Reviewing it properly would cost me more time than just fixing the parser myself.
If this is a real bug you've actually hit: reopen it with a concrete repro and a small, human-verified fix, and I'll review it. Any nontrivial design or API choice should be discussed in the issue first, before code is written. Otherwise, please disclose and verify AI-assisted contributions before submitting them in future.