[cfe-commits] r102230 - in /cfe/trunk: include/clang/Driver/ include/clang/Frontend/ lib/Frontend/ test/FixIt/

[Chris Lattner]

On Apr 24, 2010, at 10:07 PM, Nick Lewycky wrote:

> Chris Lattner wrote:
>> 
>> On Apr 23, 2010, at 6:30 PM, Nick Lewycky wrote:
>> 
>>> Author: nicholas
>>> Date: Fri Apr 23 20:30:46 2010
>>> New Revision: 102230
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=102230&view=rev
>>> Log:
>>> Teach clang -fixit to modify files in-place, or -fixit=suffix to create new
>>> files with the additional suffix in the middle.
>> 
>> Nice, does this mean I can just build with something like CXX='clang -fixit' and get auto-inplace-fixits happening?  Can you find somewhere to mention this in the users manual?
> 
> Almost! Clang still returns a failure exit code if one of the diagnostics was an error, regardless of whether the problems were fixed. You're certainly right that this is what I'm aiming for. (Also, your build will eventually fail because clang doesn't do compilation in this mode. Do we want to combine the two?)

My ideal mode is actually something like:

1. I do a make, if no errors are produced, yay, life is normal.
2. If one or more errors occur, there are two cases:
2a. If all errors have fixits, they should be applied, and clang should tell me that it applied them.  "4 errors (all fixed), 3 warnings (and 2 fixed)".  I think that the the build should still fail: if there is a bug in our fixit implementation, it is possible that the fixed code doesn't actually build right.  Forcing a rebuild is goodness imo.

2b. If any error is missing a fixit, no fixits should be applied.  For example, if the first error has a fixit and the second doesn't.  It could be that the first error was incorrectly diagnosed (and incorrectly fixed!) leading to the bogus second diagnostic.

It sounds like your implementation is already pretty close to "my ideal" :)

> Thanks for reminding me about the manual. I'll update it as soon as it's ready.

Thanks!