[cfe-commits] multifile fixits

[Douglas Gregor]

On Apr 14, 2010, at 11:48 PM, Nick Lewycky wrote:

> On 14 April 2010 07:44, Douglas Gregor <dgregor at apple.com> wrote:
> 
> On Apr 9, 2010, at 7:24 PM, Nick Lewycky wrote:
> -bool FixItRewriter::WriteFixedFile(const std::string &InFileName,
> -                                   const std::string &OutFileName) {
> +bool FixItRewriter::WriteFixedFile(FileID ID, llvm::raw_ostream *OS) {
> +  const RewriteBuffer *RewriteBuf = Rewrite.getRewriteBufferFor(ID);
> +  if (!RewriteBuf) return true;
> +  *OS << std::string(RewriteBuf->begin(), RewriteBuf->end());
> +  OS->flush();
> +  return false;
> +}
> 
> Please use OS->write() instead of forming a temporary string.
> 
> No can do. It's not backed by contiguous storage being a btree-string and there's no existing API to print these things without an std::string temporary. In a future patch I'll add a print(raw_ostream&) method to RewriteBuffer or one of its base classes, with the inefficient implementation and a FIXME to make it more awesome.

Oh, right. Sorry for being dense.

> 
> The "only fix the main file" approach was me being paranoid when fix-its first went it. I think the right answer now is for -fixit to always apply changes to all of the files (in place), and to allow a file name suffix, e.g.,
> 
> 	1) -fixit changes files in-place
> 	2) -fixit=suffix puts the changes for any file "foo.c" into "foosuffix.c"; we'll mainly use this for testing, I think.
> 
> 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.
> 
> Yes, this sounds like the right way to go forward. I'll be happy to rip out the -fixit-at logic!


I was going to type a long-winded defense of -fixit-at, but... yeah, it's really not worthwhile. Better to just -fixit inplace and get everything fixed (unless there were unfixable errors, naturally!).


	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100415/32d60c0f/attachment.html>