[cfe-commits] multifile fixits

[Douglas Gregor]

> Maybe I'm just too unix-y, but I wonder if it would help to extract the logic of re-writing the file from Clang proper. If we had -fixit-diff output a unified diff the tests can use FileCheck to ensure the diff contains appropriate edits, the users can verify changes or prepare patches for code review trivially, and updating the file becomes 'clang -fixit-diff | patch -p0'. The logic in patch should even correctly handle the most obvious cases of two patches being applied simultaneously.
> 
> Thoughts? The biggest concern I would have is portability, and I'm not opposed to providing built-in logic to apply the patch directly within Clang if needed based on the same structure that we use to build the diff. ::shrug:: I've definitely heard requests for a unified diff of the changes fixit is about to make when telling folks about it here.

The idea of generating patches to apply the fix-its is cool, but it doesn't really fit into the workflows I have for this feature. If we build project Foo with Clang and fix-its turned on, where do the patch files go? How do we eliminate redundancy when ten compiles fix the same issue?

I guess it comes down to this: if Clang modifies the files in-place, I can svn/git/cvs/hg diff after the fact to see what it did,but i don't want to do extra work to get the fixes it told me about. 


> 
> Nick
>  
> At this point, I trust fix-its enough that I'd like to add -fixit to my normal Clang build. I'm not worried about it because we should only write out the changed files if *all* errors have fix-its that were properly applied, so we only end up changing the source code when our changes produced a program that actually compiles.
> 
> Anyway, thank you for working on this! Please feel free to go ahead and commit with the few changes requested above; we can tackle the interface change separately.
> 
> 	- Doug
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100429/a0704390/attachment.html>