[Dependency Scanning] By-default do not specify '-fmodule-map-file' inputs on Swift interface dependency compilation jobs

[artemcm]

Swift interfaces will only ever query module inputs by-name, so parsing modulemap files to resolve their headers is not necessary. The exception to this is textual header ingestion directly into the Swift compiler (ClangImporter). Because then the compiler may need to resolve header includes to the corresponding module (.pcm) inputs. This requires explicitly-specified module maps, until we switch to eager module loading.

This occurs when there is a a dependency on a binary Swift module, which was built with a bridging header, and this bridging header was serialized into the .swiftmodule and must be ingested by all clients. In this case, we must ensure that all clients of said binary module, direct and transitive, are passed -fmodule-map-file= flags corresponding to dependencies of said header.

[artemcm]

swiftlang/swift-driver#1569
@swift-ci test

[cachemeifyoucan]

This only remove the option from building interface. Do you need to drop the option from ExplicitSwiftModuleLoader as well so the compilation for the main module also doesn't use this option?

[artemcm]

This only remove the option from building interface. Do you need to drop the option from ExplicitSwiftModuleLoader as well so the compilation for the main module also doesn't use this option?

Unfortunately, not yet. Furthermore, in its current state this change is not safe.
The edge case here is textual header ingestion directly into the Swift compiler (ClangImporter). Because then the compiler may need to resolve header includes to the corresponding module (.pcm) inputs. This requires explicitly-specified module maps, until we switch to eager module loading.

There are two possible cases of this:

1. We are building a source module which includes a textual bridging header. In this case, we can drop all -fmodule-map-file= flags except those that correspond to module dependencies of the bridging header itself.
2. We have a dependency on a binary Swift module, which was built with a bridging header, and this bridging header was serialized into the .swiftmodule and must be ingested by all clients. In this case, we must ensure that all clients of said binary module, direct and transitive, are passed -fmodule-map-file= flags corresponding to dependencies of said header.

(2) I will implement shortly in this PR.
(1) will require coordination with the driver, since the driver computes the set of dependencies we specify to main module compilation, it will then need to specify which of the dependencies require inclusion of the module map on the ClangImporter invocation.

[artemcm]

@swift-ci test

[cachemeifyoucan]

I am not sure about why bridging header needs a module map? Should the importer already sets up all the explicit modules including the ones needed by bridging header?

[artemcm]

I am not sure about why bridging header needs a module map? Should the importer already sets up all the explicit modules including the ones needed by bridging header?

Bridging headers require a module map because that's what aids header include resolution.
With lazy module loading, .modulemap parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module.

Once we are able to switch to eager module loading, this will no longer be necessary because we will instead be relying on module maps serialized into PCMs.

[nkcsgexi]

Thank you!