Interface ValidationError

1-indexed column within the diagram body, when known.

True when --fix writes exactly ValidationError.suggestion.

1-indexed line within the diagram body, when known.

Human-readable error message.

For a parser failure this is the translated text from explainParseError — it names the defect and cites no line, because the position is already carried structurally in ValidationError.line. So nothing in here needs body→file mapping; a caller printing it beside a file position may use it verbatim. ValidationError.raw is what carries mermaid's own citations, and is what any such mapping should act on.

One exception, and it is mermaid's rather than ours: for failures a diagram module raises after parsing succeeds, the translation layer passes mermaid's own prose through byte for byte, because that prose is written for humans already and every transformation available would make it worse. A module is free to cite a line inside that sentence, and treeView-beta does — Line 2: Unexpected indentation.... Such a citation is neither mapped nor guaranteed to agree with ValidationError.line: it does not match citationRe, so nothing here ever touches it. See #190. For that family ValidationError.raw is byte-identical to this field, so a caller rendering both will print the same sentence twice.

mermaid's original message, verbatim except that every line number matching citationRe has been mapped into body coordinates, matching ValidationError.line.

"Matching citationRe" is the whole of the guarantee: a module-raised error can word a citation in a shape that pattern does not recognize, and that number stays exactly as mermaid wrote it — see the note on ValidationError.message, which is byte-identical to this field for that family.

Present only for parser failures — structural defects never reach a parser. blockToDiagnostics maps these citations on to file coordinates when it builds a Diagnostic; code calling validateBlock directly and surfacing this beside a file position should do the same.

True when the error is a defect in the document rather than the diagram — an unclosed fence or an empty block — so no diagram was ever parsed.

Suppression directives deliberately do not apply to these. An unclosed fence has no parseable body (its body is the __UNCLOSED_FENCE__ sentinel), so no in-diagram %% directive can reach it and a -disable-file mermaid would be the only lever — a blunt one that would hide a broken fence indefinitely. Suppressing "mermaid rejected this diagram" should not also suppress "your Markdown never closed".

The one corrected source line the explanation is confident about, when it is confident about one — the author's own line, rewritten.

Quoted text, not prose: it holds whatever the author wrote, so it must never be run through mapParserMessageLines. A line reading Parse error on line 2->>Bob: hi is a sequence message, not a citation, and rewriting the number in it would corrupt the user's own source.