Simon Jakobi pushed to branch wip/sjakobi/multi-caret at Glasgow Haskell Compiler / GHC Commits: 9591c80d by Simon Jakobi at 2026-06-11T09:22:32+00:00 Shorten some comments as suggested by @sheaf. - - - - - 4 changed files: - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Types/Error.hs - compiler/GHC/Utils/Logger.hs Changes: ===================================== compiler/GHC/Tc/Errors/Ppr.hs ===================================== @@ -3764,13 +3764,8 @@ instance Diagnostic TcRnMessage where TcRnZonkerMessage{} -> [] -- | The prior occurrences of a duplicated entity, for use as the related --- locations of a \"duplicate\" diagnostic. Given all occurrences in ascending --- source order with the primary span last, return the earlier ones, omitting --- repeated spans and spans that coincide with the primary. Several --- occurrences can share a single span -- e.g. duplicate declarations brought --- into being by one TH splice -- and repeating the primary span among the --- related locations would draw its caret twice and emit it again in the JSON --- relatedSpans field. +-- locations of a \"duplicate\" diagnostic. +-- -- See Note [Choosing the primary and related spans] in GHC.Types.Error. priorOccurrences :: NE.NonEmpty SrcSpan -> [SrcSpan] priorOccurrences locs = ===================================== compiler/GHC/Tc/Errors/Types.hs ===================================== @@ -3981,13 +3981,7 @@ data TcRnMessage where TcRnDuplicateDecls :: !OccName -- ^ The name of the declarations -> !(NE.NonEmpty Name) -- ^ The individual declarations, in ascending source - -- order. The last one is the primary span of the - -- message; 'diagnosticRelatedLocations' returns the - -- earlier ones, omitting any that coincide with the - -- primary span (all occurrences can share one span, - -- e.g. when spliced by a single TH splice). See - -- Note [Choosing the primary and related spans] - -- in GHC.Types.Error. + -- order. -> TcRnMessage {-| TcRnPackageImportsDisabled is an error indicating that an import uses ===================================== compiler/GHC/Types/Error.hs ===================================== @@ -258,30 +258,14 @@ which GHC's diagnostics are forwarded by HLS: an LSP diagnostic carries a single https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17... -How the locations are rendered: - - * Related spans are additional to the primary span, not replacements for it. - The spans that receive a caret are @primary :| relatedLocations@ (see - 'GHC.Driver.Errors.printMessage' and 'defaultLogActionWithHandles'). - - * Locations are shown — both as carets and in the @At:@ list below — in - exactly the order the message author gives them: the primary span first, - then 'diagnosticRelatedLocations' as listed. The rendering layer neither - reorders nor deduplicates. - - * Not every location can be shown as a caret: carets are optional - (@-fno-diagnostics-show-caret@), and some spans have no source to display - anyway (e.g. GHCi input or TH-generated code). Locations that get no caret - are instead listed under an @At:@ heading ('pprAtLocations'; dropped when it - would name only the primary span, which the header already states). - Every location with a real source position thus appears either as a caret - or in the @At:@ list — only spans without one ('UnhelpfulSpan') are dropped - altogether — so messages need not spell the locations out in their prose. - Carets require 'IO' to read the source, so renderers other than - 'GHC.Utils.Logger.decorateDiagnostic' — in particular the pure - 'GHC.Utils.Error.pprLocMsgEnvelope', used e.g. when 'show'ing a - 'GHC.Types.SourceError.SourceError' and for deferred type errors — list - /all/ the locations under @At:@. +Locations are rendered exactly in the order they are provided. +Not every location can be shown as a caret: + - carets are optional (@-fno-diagnostics-show-caret@) + - some spans have no source to display anyway (e.g. GHCi input or TH-generated code) + - they require 'IO' to read the source code, so pure code (e.g. 'Show SourceError') + doesn't include them. + +Locations that get no caret are instead listed under an @At:@ heading. How a message author should pick and order the spans is the subject of Note [Choosing the primary and related spans]. @@ -903,11 +887,9 @@ pprAtLocations primary spans -- | When @show_caret@ is set, render carets for the given spans; otherwise -- render nothing. Either way, return the real spans that did /not/ get a caret, --- so the caller can report those locations textually. A span is missed when --- carets are disabled, or when its source is unavailable (an unhelpful span — --- dropped here — or unreadable source such as GHCi input or TH-generated code). --- The spans are kept in the order they were given in; see Note [The source span --- model for diagnostics]. +-- so the caller can report those locations textually. +-- +-- See Note [The source span model for diagnostics]. getCaretDiagnostics :: Bool -> MessageClass -> NonEmpty SrcSpan -> IO (SDoc, [RealSrcSpan]) getCaretDiagnostics show_caret msg_class spans | not show_caret = pure (empty, realSpans) ===================================== compiler/GHC/Utils/Logger.hs ===================================== @@ -479,11 +479,7 @@ decorateDiagnostic logflags msg_class srcSpan msg = addLocations _ -> [] -- The primary span is always caret'd, with the related spans drawn as - -- additional carets. Order is the message author's: the primary first, - -- then the related spans as given. 'getCaretDiagnostics' preserves that - -- order and does not deduplicate, so an author must not repeat the primary - -- among the related spans. - -- See Note [The source span model for diagnostics] in GHC.Types.Error. + -- additional carets. See Note [The source span model for diagnostics] in GHC.Types.Error. sourceSpans :: NonEmpty SrcSpan sourceSpans = srcSpan :| relatedSpans View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9591c80d912f90201549612ce9f27e58... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9591c80d912f90201549612ce9f27e58... You're receiving this email because of your account on gitlab.haskell.org.