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

[Matthieu Monrocq]

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

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

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