[cfe-dev] Proposal: Add diagnostic enumeration to libclang

[Gregory Szorc]

Currently, there is no easy way for libclang consumers to infer the
underlying type of an individual diagnostic. Operating within the bounds of
the existing API, we have the following choices:

* Parse text from clang_getDiagnosticSpelling().
* Switch off text from clang_getDiagnosticOption() and hope there is a 1:1
mapping between options and diagnostic types and hope that options don't
change over time.
* Perhaps utilize clang_getDiagnosticCategory() to aid in above

The most robust choice is probably the text parsing one. And, that is ugly
and prone to string changes and possibly translations.

I'm proposing exposing the unique per-diagnostic numeric enumeration and/or
string value to libclang. For example:

  clang_getDiagnosticID(CXDiagnostic) -> diag::warn_unused_variable (3301)
-- Implemented through Diagnostic.getID()
  clang_getDiagnosticName(CXDiagnostic) -> CXString("warn_unused_variable")
-- Implemented through DiagnosticIDs::getName()

The benefit of this exposure is that consumers can identify specific
diagnostic classes easily and with confidence.

The downside to providing this info related to the mutability of these
values over time. How constant are the enumerations? It has an impact for
compatibility of downstream applications over time, as they would have to
ensure enumeration changes are reflected. But, they would need to do this
today, albeit in a hackier way, so I think the change would be a net win.
There is also a concern for serialized diagnostics. AFAICT the diagnostic
enumeration isn't serialized in SerializedDiagnosticPrinter.cpp today. Was
this intentional over concerns of enumeration mutability over time? If so,
is the reason still valid, or can the enumeration be added to the
serialized diagnostic representation [to support this feature]?

The impetus behind this proposal is a tool I'm writing that can
automatically fix (simple) compiler warnings, such as unused parameters,
variables, etc. I'm writing this in Python, which means going through
libclang. Yes, I could write my own tool hooking into the C++ directly, but
I like the ease and convenience of a higher-level language. And, I think
other tool writers would appreciate the ability to easily distinguish
diagnostic types as well.

If there is interest, I can code up a patch.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120102/592e9471/attachment.html>