d6a9c4f0c4
A parse error raised while resolving an `#import` was rendered against the ROOT file's source — the caret landed on an unrelated line (often a comment) even though the message named the correct imported file. Two compounding causes: - core.zig wired `diagnostics.import_sources` only AFTER import resolution returned, but a parse error aborts mid-resolution (before that wiring), so the renderer had no imported sources and fell back to the root file. Wire it (and seed the main-file source) BEFORE resolving. - imports.zig emitted the diagnostic at the importer's `#import` span instead of the parser's actual error offset inside the imported file, and didn't pin the diagnostic's source_file to that file. parser.zig now records `err_end` alongside `err_offset` for a proper caret width. New `DiagnosticList.addFmtInFile` renders against an explicit source file; imports.zig uses it with `importErrSpan(&p)`. Regression test: examples/1176-diagnostics-import-parse-error-location (importer + deliberately-broken companion; caret must land in the companion).
7 lines
296 B
Plaintext
7 lines
296 B
Plaintext
// Deliberately broken: exercises import parse-error LOCATION reporting.
|
|
// These leading comment lines push the parse error down so its line number
|
|
// differs from the importer's — a mislocated caret would point here-or-wrong
|
|
// instead of at the real offending token below.
|
|
//
|
|
broken :: 1 2;
|