[PATCH] D13759: [Clang] Fix Clang-tidy modernize-use-auto warnings in headers and generated files; other minor cleanups.

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added inline comments.

================
Comment at: include/clang/AST/ASTVector.h:385
@@ -383,3 +384,3 @@
   // Allocate the memory from the ASTContext.
-  T *NewElts = new (C, llvm::alignOf<T>()) T[NewCapacity];
+  auto *NewElts = new (C, llvm::alignOf<T>()) T[NewCapacity];
 
----------------
hans wrote:
> I'm not sure this one is an improvement.
At least handling of new will be consistent. This will also silent Clang-tidy warning.

================
Comment at: include/clang/Analysis/Analyses/Consumed.h:266
@@ -266,2 +265,3 @@
   };
-}} // end namespace clang::consumed
+} // end namespace consumed
+} // end namespace clang
----------------
aaron.ballman wrote:
> I don't know whether this is an improvement or not.
This was changed for consistency with other code. I also think that it's good idea to place one statement per line.

================
Comment at: include/clang/Rewrite/Core/Rewriter.h:171
@@ -170,4 +170,3 @@
   const RewriteBuffer *getRewriteBufferFor(FileID FID) const {
-    std::map<FileID, RewriteBuffer>::const_iterator I =
-      RewriteBuffers.find(FID);
+    const auto I = RewriteBuffers.find(FID);
     return I == RewriteBuffers.end() ? nullptr : &I->second;
----------------
aaron.ballman wrote:
> Not that this matters in the cases in this code, but const iterator is not the same as const_iterator. I think these changes are a step forward in terms of readability, but a step backwards in terms of the type system.
I'm still learning C++11, so advices how to handle such situations properly are welcome!

================
Comment at: tools/libclang/Indexing.cpp:672
@@ -671,5 +671,3 @@
   IdxCtx.indexTopLevelDecl(D);
-  if (IdxCtx.shouldAbort())
-    return false;
-  return true;
+  return (!IdxCtx.shouldAbort());
 }
----------------
aaron.ballman wrote:
> The extra parens do not add any value here.
Will remove them.


Repository:
  rL LLVM

http://reviews.llvm.org/D13759