In an effort to move from unstructured text diagnostics to structured
diagnostics, while keeping support for the existing model, we need to
introduce a way to hotswap between the desired modes. The visitor
pattern is a natural ally here because it allows us to defer logic to
handlers that know the specifics of the diagnostic without cluttering
the compiler's logic.
There are two parts to the design: BasicDiagnostic, which is used as
an abstract base for errors, warnings, and remarks; and
DiagnosticContext, which is used as an abstract base for notes. We've
split diagnostics into these two categories so that it's possible for to
enrich diagnostics with multiple unrelated contexts (notes seem to trail
diagnostics in a detatched and unherded fashion). FixIts are a form of
diagnostic context.
Although parts of BasicDiagnostic and DiagnosticContext should be
generated via TableGen, we're initially implementing everything manually
so that we can prototype what is necessary: it will be far easier to do
this with a handful of diagnostics than to also figure out how to
integrate this into TableGen at the same time.
Reviewers should note that testing is currently lacking. Tests for the
diagnostic framework seem to be nonexistent; this should probably
change.
Depends on: D109701
To make sure I understand, notes are one context, but are error/warning/remarks another context, and same for fixits?
I'm having a hard time understanding how you expect to use this; in the diagnostics engine, notes are like any other diagnostic, so are you going to look at the diagnostic ID and dispatch to either the BasicDiagnostic or the DiagnosticContext interface? I'd appreciate a bit more information on how this separation works.