[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