jhheider / edikt / 30142874849

96%

Build Type

push

github

Committed by web-flow

Commit Message

feat(parser): hyphenated bare keys on an assignment target (#62)

`.dev-dependencies.serde_json = "1"` now works without quoting.

The insight is that an assignment target must be a path, so subtraction
cannot occur there. That removes the ambiguity that forces quoting
everywhere else: in this one position a hyphen between two identifier
characters is unambiguously part of the key, so edikt can parse it
instead of asking people to quote the most common key in a Cargo.toml.

Purely additive. Every expression this accepts previously failed, since
a subtraction on the left of `=` was never legal. `try_assign_target`
parses speculatively and rewinds on any miss, so no non-assignment
expression can parse differently than before, and joining requires the
tokens to abut, so `.a - b` is still an operator.

This replaces the old `reject_hyphen_key_lhs` diagnostic for the shapes
it can now parse. That check stays for LHS shapes the path parser cannot
handle (a pipe, a parenthesized expression), where naming the cause
still beats failing later with "left side of an assignment must be a
path".

Queries are a different matter and are left alone: `.total-length` is a
legitimate subtraction of the `length` builtin, so a hyphen there cannot
be guessed at. Those keep needing `."dev-dependencies"`. What is new is
that a query whose parse *fails* now says why: `.dev-dependencies.serde_json`
used to die at the `.` after `dependencies` with "unexpected trailing
token `.`", which named neither the hyphen nor the fix, and now gets the
same message the LHS check produces.

Found by dogfooding edikt on a real Cargo.toml edit from another repo,
where the old error was opaque enough that I worked around it twice
instead of reading it.


Claude-Session: https://claude.ai/code/session_016wrSiZfmH1jnLESCR41Xzw

Co-authored-by: Claude <noreply@anthropic.com>

Coverage Stats

192 of 197 new or added lines in 1 file covered. (97.46%)

12 existing lines in 1 file now uncovered.

10701 of 11157 relevant lines covered (95.91%)

93.21 hits per line