[PATCH] cp11-migrate: Integration with LibFormat.

[Edwin Vane]

  What is the cost of updating range info every transform? I have a feeling this new range management stuff is more complex than it needs to be. It's not done right now but the plan was to store replacements for headers to write them to disk at the end. We could do something similar for sources too and then we could just do the range calculation once at the end.


================
Comment at: cpp11-migrate/Core/FileOverrides.h:37
@@ +36,3 @@
+///
+// FIXME: clang::tooling::Range could be used if they were a bit more flexible
+// (e.g: offset and length reassignable)
----------------
Is there a reason we can't improve clang::tooling::range?

================
Comment at: unittests/cpp11-migrate/FileOverridesTest.cpp:21
@@ -19,18 +20,3 @@
 
-TEST(SourceOverridesTest, Interface) {
-  llvm::IntrusiveRefCntPtr<clang::DiagnosticOptions> DiagOpts(
-      new DiagnosticOptions());
-  DiagnosticsEngine Diagnostics(
-      llvm::IntrusiveRefCntPtr<DiagnosticIDs>(new DiagnosticIDs()),
-      DiagOpts.getPtr());
-  FileManager Files((FileSystemOptions()));
-  SourceManager SM(Diagnostics, Files);
-  StringRef FileName = "<text>";
-  StringRef Code =
-      "std::vector<such_a_long_name_for_a_type>::const_iterator long_type =\n"
-      "    vec.begin();\n"
-      "int   x;"; // to test that it's not the whole file that is reformatted
-  llvm::MemoryBuffer *Buf = llvm::MemoryBuffer::getMemBuffer(Code, FileName);
-  const clang::FileEntry *Entry =
-      Files.getVirtualFile(FileName, Buf->getBufferSize(), 0);
-  SM.overrideFileContents(Entry, Buf);
+// Test fixture object that setup some files once for all test cases and remove
+// them when the tests are done.
----------------
These refactoring changes are not specific to the reformat stuff. Can you separate them into another patch?


http://llvm-reviews.chandlerc.com/D1136