Currently each diagnostic is its own type and required to have 3 things:
A static constexpr string_view kCategory describing the kind of error.
A static constexpr string_view kName uniquely identifying the error. Uniqueness is not enforced, but this should be globally unique.
A ToMessage member function which converts the object into a diagnostic::DiagnosticMessage.
Naming aside, The idea here is that we want a somewhat universal format for diagnostics so they can be passed to different diagnostic consumption mechanisms. Diagnostics printed to a terminal should likely be formatted differently than those streamed to a webserver. In essence, DiagnosticMessage is intended to be a relatively simple "document format" that can by stylized differently in different contexts.
One such use case we have not yet designed for is having a language server pass information to an editor. It seems mostly straightforward to have a diagnostic consumer that extracts just the source ranges and diagnostic name information for this purpose. I suspect there's a lot that can be improved about the API considering this use-case that we haven't looked at before.
Currently each diagnostic is its own type and required to have 3 things:
kCategory
describing the kind of error.kName
uniquely identifying the error. Uniqueness is not enforced, but this should be globally unique.diagnostic::DiagnosticMessage
.Naming aside, The idea here is that we want a somewhat universal format for diagnostics so they can be passed to different diagnostic consumption mechanisms. Diagnostics printed to a terminal should likely be formatted differently than those streamed to a webserver. In essence,
DiagnosticMessage
is intended to be a relatively simple "document format" that can by stylized differently in different contexts.One such use case we have not yet designed for is having a language server pass information to an editor. It seems mostly straightforward to have a diagnostic consumer that extracts just the source ranges and diagnostic name information for this purpose. I suspect there's a lot that can be improved about the API considering this use-case that we haven't looked at before.