[PATCH] D121997: [clang][driver] Fix compilation database dump with multiple architectures

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.


================
Comment at: clang/test/Driver/compilation_database_multiarch.c:2
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: %clang -c %s -o %t/out -arch x86_64 -arch arm64 -MJ %t/compilation_database.json
+// RUN: FileCheck --input-file=%t/compilation_database.json %s
----------------
Usually driver tests don't depend on the `-cc1` working. The `-cc1` depends on the backends. You'd need to check that the relevant targets have been built and linked in. It'd be better to keep this isolated to the driver?

Is there a way to get the driver to dump the compilation database only (without actually running the actions)?

E.g., will `-###` still emit the compilation database? Looks like not:
```
  // If this is a dry run, do not create the compilation database file.
  if (C.getArgs().hasArg(options::OPT__HASH_HASH_HASH))
    return;
```
But maybe there's some other way to avoid running the actions. Or, we can add something like `-MJ-only <cdb>`, which acts like `-MJ <cdb>` and then exits before running the actions.


================
Comment at: clang/test/Driver/compilation_database_multiarch.c:5-6
+
+// CHECK:      { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", "arguments": [{{.*}} "--target=x86_64-apple-macosx12.0.0"]},
+// CHECK-NEXT: { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", "arguments": [{{.*}} "--target=arm64-apple-ios5.0.0"]},
----------------
I guess this is off topic, but this is the wrong output. Would be good to fix this — maybe first to avoid adding a test for the wrong behaviour. Running on macOS 12, I would expect:
```
% clang -arch x86_64 -arch arm64 /dev/null -x c -###
```
to emit
```
".../path/to/clang" "-cc1" "-triple" "x86_64-apple-macosx12.0.0" ...
".../path/to/clang" "-cc1" "-triple" "arm64-apple-macosx12.0.0" ...
```
and that's what I get from the clang that comes with Xcode. But I reproduced the incorrect output you're checking for here with the clang at llvm.org.

Is there something we forgot to upstream? @arphaman, do you know?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121997