[PATCH] D137534: [C++20] [Modules] [ClangScanDeps] Allow clang-scan-deps to without specified compilation database in P1689 (3/4)

Jan Svoboda via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 3 12:43:45 PST 2023


jansvoboda11 added a comment.

While I was not suggesting using compilation database instead of the approach taken by this patch, I appreciate your explanation. But it still leaves me wondering whether generating one compilation database per file-to-be-scanned would be a reasonable strategy? That might help us avoid increasing the complexity of the `clang-scan-deps` command-line interface.

If we really want to avoid writing compilation databases, I think that `clang-scan-deps -format=p1689 -- <clang_flags> -std=c++20 <input> -o <output>` is much cleaner/generic/reusable than `clang-scan-deps -format=p1689 --p1689-targeted-file-name=<input> --p1689-targeted-output=<output> -- <clang_flags> -std=c++20`. I understand that `FixedCompilationDatabase` currently doesn't know what the input/output is unless you explicitly pass that in. What if we were able to construct some kind of `CompilationDatabase` by properly parsing the given complete command line into `CompilerInvocation` and poking at `FrontendOptions`?



================
Comment at: clang/lib/Tooling/CompilationDatabase.cpp:378
+  if (!FilePath.empty())
+    ToolCommandLine.push_back(std::string(FilePath));
+  CompileCommands.emplace_back(Directory, FilePath, std::move(ToolCommandLine),
----------------
I don't think this is correct in cases where the command line already contains an input, or is malformed. As an example, if the last element is an option that expects a value (e.g. `"-ferror-limit"`), appending `FilePath` will trigger diagnostics in the driver that the argument to `-ferror-limit` is not numeric and that an input needs to be specified. While the correct/expected behavior would be to emit single diagnostic complaining about missing value for the last option.

Clang's tooling is littered with ad-hoc command-line parsing/manipulation and it's rarely handling all the edge-cases. I'd prefer this complexity lived somewhere outside of Clang, in the tool that actually constructed the command line in the first place.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137534/new/

https://reviews.llvm.org/D137534



More information about the cfe-commits mailing list