[cfe-dev] Proposal: Add diagnostic enumeration to libclang
gregory.szorc at gmail.com
Mon Jan 9 21:28:41 PST 2012
The fixit conversation is interesting. But, I don't think I ever got a
response to the proposal part of this email. Anybody care to weigh in on
On 1/2/2012 3:01 PM, Gregory Szorc wrote:
> 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
> 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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev