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:<br><br>* Parse text from clang_getDiagnosticSpelling().<br>
* 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.<br>* Perhaps utilize clang_getDiagnosticCategory() to aid in above<br>
<br>The most robust choice is probably the text parsing one. And, that is ugly and prone to string changes and possibly translations.<br><br>I'm proposing exposing the unique per-diagnostic numeric enumeration and/or string value to libclang. For example:<br>
<br>  clang_getDiagnosticID(CXDiagnostic) -> diag::warn_unused_variable (3301) -- Implemented through Diagnostic.getID()<br>  clang_getDiagnosticName(CXDiagnostic) -> CXString("warn_unused_variable") -- Implemented through DiagnosticIDs::getName()<br>
<br>The benefit of this exposure is that consumers can identify specific diagnostic classes easily and with confidence.<br><br>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]?<br>
<br>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.<br>
<br>If there is interest, I can code up a patch.<br><br>Greg<br>