[Dependency Scanning] Record header dependencies of binary Swift module dependencies

[artemcm]

When we encounter a pre-built Swift binary module dependency (without an interface file), such module may have been built with a bridging header, which must still be present and is referenced by the binary .swiftmodule as either a .h or, more-likely, a pre-built .pch in a fully-explicit build.

Clients must be able to know about such header dependencies in order to be able to import this binary module, because this binary module may be referencing types brought in via its bridging header. The build-system client (swift-driver) will then ensure these header dependencies are fed as inputs to all requiring compilation tasks.

[artemcm]

@swift-ci test

[nkcsgexi]

Makes sense to me!

[cachemeifyoucan]

Is there any example use case for this? I assume you can't really ship a swift module that has bridging header dependencies?

The main reason to ask is this is going to a very hard to support corner case for caching, because this is not tracking the dependencies for the bridging header itself. Does build system/swift driver need to be aware of that in non-caching builds?

I think the only solution for support caching for this case will be encoding the CASID for the dependencies in swift module. Unfortunately it means that you can only depend on swift binary module builds from CAS when enable caching.

[artemcm]

Is there any example use case for this? I assume you can't really ship a swift module that has bridging header dependencies?

PCHs started being a part of this field with Explicit modules, since we started feeding them in explicitly as inputs. We do have the alternative of referencing them as a .h file dependency, too.

The main reason to ask is this is going to a very hard to support corner case for caching, because this is not tracking the dependencies for the bridging header itself. Does build system/swift driver need to be aware of that in non-caching builds?

Perhaps binary modules built with a bridging header need to separately also track dependencies of the bridging header itself?

I think the only solution for support caching for this case will be encoding the CASID for the dependencies in swift module. Unfortunately it means that you can only depend on swift binary module builds from CAS when enable caching.

[cachemeifyoucan]

Talk with Artem offline. Caching for this case needs a different solution orthogonal to this fix.

Nit: miss a test case for the dependency scanner that make sure the -include-pch option is generated.

Otherwise, LGTM.

[artemcm]

@swift-ci test