<br><br><div class="gmail_quote">Le 3 janvier 2012 00:01, Gregory Szorc <span dir="ltr"><<a href="mailto:gregory.szorc@gmail.com">gregory.szorc@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br><br></blockquote><div>I appreciate people working on libclang and the Python bindings in general, since it means that it makes it easier for everyone to access a quality C++ parser instead of hacking around...<br><br>
However in your particular case (fixing simple warnings) Clang already has such fixes available (through Fix Hints) for many trivial warnings, so I am surprised that you would need to completely reimplement them. Perhaps it is those Fix Hints that should be exposed through the Python API ?<br>
</div></div><br>I hope better informed people will chime in...<br><br>--Matthieu<br>