-
f36bb9d0
by Simon Jakobi at 2026-06-10T15:46:09+02:00
Diagnostics: adopt a rightmost-primary convention for duplicate diagnostics
When a diagnostic reports the same entity occurring at several sites
(TcRnDuplicateDecls, TcRnBindingNameConflict, TcRnDuplicateExport,
TcRnDuplicateNamedDefaultExport), make the primary span the last
occurrence in source order, with the earlier occurrences as related
locations in ascending order. Duplicates usually arise because the later
occurrence was just added, so the primary span -- the location the user
is sent to, and the one an editor marks -- is the occurrence they most
likely need to act on. This matches other compilers (clang's
"redefinition of 'x' / note: previous definition is here", and similarly
rustc and TypeScript), and it gives the unlabelled carets a reading: the
first caret is the site to fix, the following ones are the prior sites
in source order. The convention is documented in
Note [The source span model for diagnostics], including a remark on how
rustc-style file-order display could be reintroduced once per-span
labels (#23414) exist.
Concretely:
* addDupDeclErr reports at NE.last again (as on master), and
dupNamesErr now reports at the last occurrence rather than the first;
the related locations for both become NE.init.
* The duplicate-export warnings already comply: they are raised at the
second occurrence with the first as the related location.
* The expected outputs of the duplicate-export tests (ExportWarnings6,
haddock.Test, mod128, T11959, T23318, T25901_exp_dup_wc_3/4) had
become stale when the renderer stopped sorting the "At:" list; their
"At:" entries are now in author order (primary first).
* MultiCaretFallback's phantom file is renamed so that it sorts before
the real file, keeping the phantom span a related location and the
test exercising the "At:" fallback.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-
45554a02
by Simon Jakobi at 2026-06-10T15:52:00+02:00
Split Note [The source span model for diagnostics]
The Note had grown to cover two audiences at once: what the primary/related
span model is and how the rendering layer treats it, versus how a message
author should pick and order the spans. Move the author-facing guidance
(pick one real location rather than a synthetic combined span, order related
spans deterministically, the rightmost-primary convention for duplicate
diagnostics) into a new Note [Choosing the primary and related spans], and
retarget the references at the emission sites accordingly.
No content changes beyond the reorganisation and a slight tightening of the
ordering bullet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-
a858aea9
by Simon Jakobi at 2026-06-10T16:21:58+02:00
Note [Choosing the primary and related spans]: trim constructor list
Give two examples of duplicate diagnostics rather than enumerating all
four, so the Note does not need updating whenever one is added.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-
672e43e1
by Simon Jakobi at 2026-06-10T16:25:48+02:00
Tighten the diagnostic span notes
In Note [Choosing the primary and related spans], fold the three
paragraphs of the duplicate-diagnostics convention into one: the
squiggle/jump-target explanation restated the model note, and the
two rustc passages said the same thing twice. Also compress the LSP
correspondence and the "At:" fallback bullet in
Note [The source span model for diagnostics].
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>