<br><br><div class="gmail_quote">Le 3 janvier 2012 20:16, 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">
<div class="gmail_quote"><div class="im">On Tue, Jan 3, 2012 at 9:28 AM, Matthieu Monrocq <span dir="ltr"><<a href="mailto:matthieu.monrocq@gmail.com" target="_blank">matthieu.monrocq@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div>
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></blockquote></div><div><br>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.<br>

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

</div></div>
</blockquote></div><br>Ah indeed, you might wish to provide corrections beyond what Clang does (and can) propose.<br><br>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.<br>
<br>I was just trying to made sure you had not overlooked this existing facility.<br><br>-- Matthieu<br>