CTU mapping is not interpreted correctly

[temyurchenko]

In 5cc18516c4839fccc64b54eaa5aa447a8e1ed8fa, there is a diff:

-    const size_t Pos = Line.find(" ");
-    if (Pos > 0 && Pos != std::string::npos) {
-      StringRef LineRef{Line};
-      StringRef LookupName = LineRef.substr(0, Pos);
-      if (Result.count(LookupName))
+    StringRef LineRef{Line};
+    const size_t Delimiter = LineRef.find(" ");
+    if (Delimiter > 0 && Delimiter != std::string::npos) {
+      StringRef LookupName = LineRef.substr(0, Delimiter);
+
+      // Store paths with posix-style directory separator.
+      SmallVector<char, 32> FilePath;
+      llvm::Twine{LineRef.substr(Delimiter + 1)}.toVector(FilePath);
+      llvm::sys::path::native(FilePath, llvm::sys::path::Style::posix);
+
+      bool InsertionOccured;
+      std::tie(std::ignore, InsertionOccured) =
+          Result.try_emplace(LookupName, FilePath.begin(), FilePath.end());
+      if (!InsertionOccured)
         return llvm::make_error<IndexError>(
             index_error_code::multiple_definitions, IndexPath.str(), LineNo);
-      StringRef FileName = LineRef.substr(Pos + 1);
-      SmallString<256> FilePath = CrossTUDir;
-      llvm::sys::path::append(FilePath, FileName);
-      Result[LookupName] = std::string(FilePath);

The code creates a mapping of FilePaths containing the definition of LookupNames. The FilePaths are fetched from a CTU index file at IndexPath. Note, how in the version before CrossTUDir was prepended to the FilePath. In the new version, it doesn't.

That constitutes a problem. The documentation on using CodeChecker to generate a CTU database, gives us an index file with relative paths. If one doesn't append the CTU directory to such a path, the AST file is not going to be found. Which is exactly what happens.

Perhaps, the patch was necessary to support the on-demand CTU analysis, but it seems to have broken the PCH-based one. Or, perhaps, the documentation is outdated.

cc @gamesh411.

[temyurchenko]

https://github.com/Ericsson/codechecker/pull/3707 looks somewhat relevant.