From: Chris Lattner
As you can see, adding and producing a diagnostic is pretty straightforward. The hard part is deciding exactly what you need to say to help the user, picking a suitable wording, and providing the information needed to format it correctly. +The good news is that the call site that issues a diagnostic should be +completely independent of how the diagnostic is formatted and in what language +it is rendered.
@@ -356,17 +362,27 @@ code, the source ranges, and the caret. However, this behavior isn't required.Another implementation of the DiagnosticClient interface is the 'TextDiagnosticBuffer' class, which is used when clang is in -verify mode. -Instead of formatting and printing out the diagnostics, this implementation +Instead of formatting and printing out the diagnostics, this implementation just +captures and remembers the diagnostics as they fly by. Then -verify compares +the list of produced diagnostics to the list of expected ones. If they diagree, +it prints out its own output.
-Clang command line, buffering, HTMLizing, etc.
+There are many other possible implementations of this interface, and this is +why we prefer diagnostics to pass down rich structured information in arguments. +For example, an HTML output might want declaration names be linkified to where +they come from in the source. Another example is that a GUI might let you click +on typedefs to expand them. This application would want to pass significantly +more information about types through to the GUI than a simple flat string. The +interface allows this to happen.
Not possible yet! Diagnostic strings should be written in UTF-8, the client -can translate to the relevant code page if needed.
+can translate to the relevant code page if needed. Each translation completely +replaces the format string for the diagnostic.