1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
//! Rules for valid keys and dotted paths (spec § 4).
//!
//! Under spec 0.6.0:
//! - Each key segment is trimmed of leading/trailing ASCII whitespace,
//! then validated **before** escape-decoding — this function looks
//! at the raw, still-escaped segment text, not the decoded result.
//! That ordering matters: § 3.7 defines ten key escapes (`\\`, `\,`,
//! `\}`, `\]`, `\{`, `\[`, `\n`, `\r`, `\.`, `\:`), so a decoded
//! segment legitimately CAN contain a `,` / `{` / `}` / `[` / `]` /
//! LF / CR byte when it arrived via its escape. Checking the raw
//! text instead lets those through while still rejecting the same
//! byte when it appears bare (unescaped) in the source — which is
//! what actually needs to be forbidden, e.g. so a raw `,` inside an
//! inline compound can't be mistaken for anything but the compound's
//! own pair/item separator.
//! - Internal whitespace (space / tab) is allowed inside segments.
//! - `#` is allowed (single `#` has no special meaning in 0.6.0).
//! - Forbidden RAW (unescaped) bytes: `,`, `{`, `}`, `[`, `]`, line
//! terminators (`LF`, `CR`), and `(` / `)` — the last two have no
//! § 3.7 escape at all, so they are forbidden even when the caller
//! tries to escape them (`decode_key_segment` rejects `\(` / `\)`
//! as an unrecognised escape before this distinction would matter).
//! A byte immediately following an unescaped `\` is always skipped
//! here — validating that it is one of the ten recognised escapes
//! is `decode_key_segment`'s job, not this function's.
//! - Empty (or empty-after-trim, by the caller) → `EmptyKey`.
pub