[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

Daniel Marjamäki via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Mar 31 02:32:16 PDT 2017


danielmarjamaki added inline comments.


================
Comment at: include/clang/AST/ASTContext.h:42
 #include "clang/Basic/Specifiers.h"
+#include "clang/Basic/VersionTuple.h"
 #include "llvm/ADT/APSInt.h"
----------------
I don't see why this is included here.


================
Comment at: include/clang/AST/Mangle.h:55
   const ManglerKind Kind;
+  // Used for cross tranlsation unit analysis.
+  // To reduce the risk of function name collision in C projects, we force
----------------
tranlsation => translation


================
Comment at: lib/AST/ASTContext.cpp:1457
+    return nullptr;
+  for (Decl *D : DC->decls()) {
+    const auto *SubDC = dyn_cast<DeclContext>(D);
----------------
could add a "const" perhaps


================
Comment at: lib/AST/ASTContext.cpp:1491
+  std::string MangledFnName = getMangledName(FD, MangleCtx.get());
+  std::string ExternalFunctionMap = (XTUDir + "/externalFnMap.txt").str();
+  ASTUnit *Unit = nullptr;
----------------
as far as I see ExternalFunctionMap can be moved into the subscope.


================
Comment at: lib/AST/ASTContext.cpp:1500
+      std::string FunctionName, FileName;
+      while (ExternalFnMapFile >> FunctionName >> FileName)
+        FunctionFileMap[FunctionName] = (XTUDir + "/" + FileName).str();
----------------
I would recommend that a parser is added that make sure the file data is correct/sane. If there is some load/save mismatch now or in the future or if the user choose to tweak the file for some reason, the behaviour could be wrong.



================
Comment at: lib/AST/ASTContext.cpp:1502
+        FunctionFileMap[FunctionName] = (XTUDir + "/" + FileName).str();
+      ExternalFnMapFile.close();
+    }
----------------
well.. I believe it's redundant to close this explicitly since the std::ifstream destructor should do that. But it doesn't hurt doing it.


================
Comment at: lib/Basic/SourceManager.cpp:2028
 /// \brief Determines the order of 2 source locations in the translation unit.
+/// FIXME: It also works when two locations are from different translation unit.
+///        In that case it will return *some* order.
----------------
I am not good at english. But I believe unit=>units.


================
Comment at: lib/Basic/SourceManager.cpp:2126
   }
-  llvm_unreachable("Unsortable locations found");
+  // FIXME: Source locations from different translation unit.
+  return LOffs.first < ROffs.first;
----------------
I am not good at english. But I believe unit=>units.


================
Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:48
+#include <sys/file.h>
+#include <unistd.h>
+#include <fstream>
----------------
I believe sys/file.h and unistd.h are posix includes.


================
Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:433
+    return;
+  int fd = open(fileName.c_str(), O_CREAT|O_WRONLY|O_APPEND, 0666);
+  flock(fd, LOCK_EX);
----------------
this is posix file-I/O


================
Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:56
+  if (Sources.empty())
+    return 1;
+
----------------
Maybe use the EXIT_FAILURE instead


================
Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:66
+  for (StringRef SourceFile : Sources) {
+    char *Path = realpath(SourceFile.data(), nullptr);
+    if (Path)
----------------
This is posix function as far as I know.


================
Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:72
+
+  return 0;
+}
----------------
EXIT_SUCCESS is also possible however I guess that is 0 on all implementations.


================
Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:32
+#include <string>
+#include <sys/file.h>
+#include <unistd.h>
----------------
posix includes


================
Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:153
+
+      if (!FileName.empty())
+        switch (FD->getLinkageInternal()) {
----------------
I do not see how FileName could be empty. It always starts with "/ast/" right?


================
Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:193
+  lockedWrite(BuildDir + "/definedFns.txt", DefinedFuncsStr.str());
+  std::stringstream CFGStr;
+  for (auto &Entry : CG) {
----------------
if a STL stream will be used I recommend the std::ostringstream instead


================
Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:244
+    errs() << "Exactly one XTU dir should be provided\n";
+    return 1;
+  }
----------------
maybe use EXIT_FAILURE


================
Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:257
+  Tool.run(newFrontendActionFactory<MapFunctionNamesAction>().get());
+}
----------------
no return.


================
Comment at: tools/xtu-analysis/xtu-analyze.py:29
+
+threading_factor = int(multiprocessing.cpu_count() * 1.5)
+analyser_output_formats = ['plist-multi-file', 'plist', 'plist-html',
----------------
does this mean that if there are 4 cores this script will by default use 6 threads? isn't that too aggressive?


Repository:
  rL LLVM

https://reviews.llvm.org/D30691





More information about the cfe-commits mailing list