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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
