/**
 * The IDF character rules, in one place.
 *
 * The grammar is small:
 *   - `!` starts a comment running to the end of its line
 *   - `,` separates fields
 *   - `;` terminates a statement
 *   - everything else is field text
 *
 * There are no string literals and no escape sequences, so a comma cannot occur inside a field
 * value and an `!` always starts a comment. Real files depend on both.
 *
 * A hand-written character walk rather than a regex. The Python library matches objects with a
 * `(?:[^;!]*(?:![^\n]*\n)?)*?` inner loop; that is a nested quantifier, so it backtracks badly on
 * malformed input and cannot report where the problem was. A scan is about the same amount of
 * code, is linear in the input, and always knows its line number.
 *
 * **Why this file exists at all.** Every position this library reports depends on the syntax layer
 * and the model-building read agreeing about where a field begins and ends. Two implementations of
 * "step over a comment between a separator and its value" that differ by one character put a
 * finding on the wrong field, and that class of bug stays invisible until a file puts a comment
 * somewhere unusual. The rules used to exist twice, once inside `lex` and once inside the
 * `fieldLine` helper of `idf.ts`; both are now callers of this scan (research R3).
 *
 * **This module is internal and stays internal.** It is not exported from the package root. The
 * syntax layer, which is public, is what a consumer outside the package reaches for; keeping the
 * scan itself unexported is the reason the layer ships in core rather than beside the language
 * service, because a package boundary drawn around both halves would have forced this file into a
 * published export purely so the other half could reach it.
 *
 * @internal
 */
export {};
//# sourceMappingURL=scan.d.ts.map