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

[Ben Boeckel via Phabricator via cfe-commits]

ben.boeckel added a comment.

In D137534#4024022 <https://reviews.llvm.org/D137534#4024022>, @jansvoboda11 wrote:

> 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.

My preferred solution is to just use `clang` directly, but this is where we ended up. A database file would still require `-MF` flags for the scan itself (unless it expects us to "lie" about the command line that we'll actually use…which is already true since we'll have to skip the `@module_info` file as it either won't exist or may be out-of-date). We also need to communicate:

- the file the scanning output should go to
- if `-MF` isn't "stolen" from the "lying" command line, we'll need those flags too

I guess I don't see the benefit of writing out all of these JSON files dealing with escaping and command line parsing when we can just communicate in the same language we do with the compiler anyways (the command line) instead of communicating through a translator (JSON).

> 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`?

You still need to know where to put the P1689 <https://reviews.llvm.org/P1689> output and where the make-style dependency info for files read during the scan need to go. I see these as distinctly `clang-scan-deps` flags and should be *before* the `--`. Basically, it seems weird to me to have the clang flags end up telling the scanner where to put the `-MF` info (as it is now, but you want even fewer flags which I don't think is workable as the information just isn't there).


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

https://reviews.llvm.org/D137534