[Explicit Module Builds] Rely on Clang dependencies' ContextHash to determine the PCM output filename

[artemcm]

The driver previously implemented a scheme where it computed an output path for the PCMs of clang module dependencies by hashing the command-line used to build the PCM plus a set of special arguments determined by the depending Swift module that made the PCM unique to the depending Swift module in the build graph. This was previously done first and foremost to accomodate the fact that we used to have Clang modules built against different target triples in the build graph.

The driver would previously execute a dependency scan, and follow it up with a re-scan of relevant clang modules which we require to have dependency info about at a target triple that is different from the main module's target triple. With the introduction of '-clang-target', we are aiming to ensure that '-target' triple of all Clang modules built matches that of the top-level Swift main module being built; therefore, making re-scanning and manual hashing of the PCM output filename unnecessary.

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test

[nkcsgexi]

by hashing the command-line used to build the PCM plus a set of special arguments determined by the depending Swift

To refresh my memory about this, why are these special arguments not part of the PCM building command?

[artemcm]

by hashing the command-line used to build the PCM plus a set of special arguments determined by the depending Swift

To refresh my memory about this, why are these special arguments not part of the PCM building command?

The only example really is a depending Swift module's target triple. Say we're building main module A for macOS 11.0, which depends on B, whose interface specifies a target of macOS 10.0, and both A and B depend on Clang module C.

The dependency scan is done with the specified target of the main module - macOS 11.0, but when building B, we would note its target triple as a special PCM argument, which would really only be the target triple.

Then during planning, we would note that C is depended upon by two modules whose "special" PCM argument sets are different (because of the triple difference) so we would re-scan C by appending these special arguments to the scanner commands, getting us different scan results of C, depending on its target triple. These different scans actually would propagate down to the eventual build commands to build C, we would just have two of them.

Now that we have settled on a scheme where we aim to only build modules for a single target (that of the main module), I am hoping we can move away from this scheme entirely. Simply execute a scan at the main module triple and use the results of this scan to form a complete build graph.

In my testing, since we introduced the notion of -clang-target, I haven't yet encountered a case where it broke a build, so I am hopeful we will be able to remove the re-scanning logic altogether. 🤞🏼

[nkcsgexi]

Makes sense. Thank you for explaining the details!