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

[Gregory Szorc]

On Tue, Jan 3, 2012 at 9:28 AM, Matthieu Monrocq <matthieu.monrocq at gmail.com
> wrote:

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

The Python API *does* expose the Fix-it Hints currently. However, there are
no Fix-it Hints for some warnings that I wish to correct. You can make the
argument that Clang should provide Fix-it Hints for more warnings. But,
there are plenty of scenarios where there are multiple remedies to a
warning. Which one do you suggest? Do you emit multiple hints? How do you
control the application of these? Maybe your remedy for an unused function
parameter is to remove the parameter itself and change the function
signature (a valid choice in some scenarios). Does Clang then do the
refactoring of callers for you? Probably not: Clang is a compiler, not an
IDE. But, where do you draw the line? Providing more Fix-it Hints is a deep
rabbit hole. And, there will always be areas that Clang doesn't want to
tread, necessitating the existence of tools.

This proposal aims to empower those tools with knowledge they don't have
today. And, I think there are use cases outside of my tool. A sign of a
good API is it enables usage beyond what you had originally conceived.
Exposing diagnostic enumerations would enable such usage for anyone dealing
with diagnostics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120103/69e913d8/attachment.html>