[libclang] Add API to generate a reproducer for the explicitly-built modules.

[vsapsai]

Capturing a single -cc1 command to reproduce a bug with the explicitly-built modules isn't sufficient, we need to know what .pcm files were built and how.

rdar://59743925

[vsapsai]

Right now I'd like to get a high-level opinion if such an approach for reproducers is reasonable. This feature will have more commits, to get an idea of how it is supposed to look like you can check users/vsapsai/reproducer-explicitly-built-modules branch.

[vsapsai]

An example of API usage is in swiftlang/swift-build#455

[vsapsai]

By the way, this doesn't work as a reproducer for dependency scanning, I'm just capturing the scanning results. My hope that with including the original command [used for scanning] and with the captured files you can still do something like

c-index-test core --scan-deps -- original_command_from_reproducer

After landing the proposed level of reproducing we can think how to support scan-deps better.

I was considering an alternative of invoking clang-scan-deps from the shell script and building modules based on the scanning results. But I've decided that embedding a little build system in a shell script is too much complexity and not justified at this stage. Maybe we'll see a need for something like that, then we can bite the bullet and add the required complexity.

[vsapsai]

I had an idea of adding DependencyScanningWorker to the reproducer generation API so that we can capture some internal worker state to help with the debugging. But after additional consideration I think it is too vague and unclear as I don't have specific use cases when it should help. And such functionality we can always add in a new API version.

[vsapsai]

Ping.

[jansvoboda11]

I'd like the API changes from users/vsapsai/reproducer-explicitly-built-modules (and the addition of const char *ModuleName to align with the scan API that we talked about offline) to be included in this PR. C APIs cannot change between Clang versions, so getting this right in the first commit makes the most sense to me.

[vsapsai]

Added ModuleName [that's not used right now]. And added another commit with ReproducerLocation to this branch.

[jansvoboda11]

LGTM, but let's see if @Bigcheese or @benlangmuir have any objections.

[benlangmuir]

Should this have an entry point in clang-scan-deps? It's unusual to have something in CDependencies that doesn't have an equivalent clang-scan-deps command-line interface, though it's not strictly necessary

[vsapsai]

Should this have an entry point in clang-scan-deps? It's unusual to have something in CDependencies that doesn't have an equivalent clang-scan-deps command-line interface, though it's not strictly necessary

I agree it is a good idea. But when I've started working on it, I've realized that for the proper API I need a build system ready to use it. And I don't have such a build system. I'm not strongly against it but I'd rather avoid developing functionality nobody uses.

[benlangmuir]

We need to copy the strings/arrays so that their lifetime is maintained by the options object.