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

Matthieu Monrocq matthieu.monrocq at gmail.com
Wed Jan 4 11:41:29 PST 2012

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

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

Ah indeed, you might wish to provide corrections beyond what Clang does
(and can) propose.

Indeed one of the driving philosophy is that Clang should only provide Fix
Hints when there is a single possible correction, lest it broke the code

I was just trying to made sure you had not overlooked this existing

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

More information about the cfe-dev mailing list