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

[Matthieu Monrocq]

Le 3 janvier 2012 00:01, Gregory Szorc <gregory.szorc at gmail.com> a écrit :

> 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
>
>
> 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...

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 ?

I hope better informed people will chime in...

--Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120103/c4af2d96/attachment.html>