Separate parsing out Swift and Clang modules from the explicit modulemap

[artemcm]

Since #63178 added support for Clang modules in the explicit module map, it used the convention of specifying artifacts of a Swift module with a given name and a Clang module with the same name under the same entry. This change separates an individual entry to represent an individual module, even if they have the same name (but one is Swift and one is Clang).

The current parsing logic just overwrites the corresponding entry module in a hashmap so we always only preserved the module that comes last, with the same name. This change separates the parsing of the modulemap JSON file to produce a separate Swift module map and Clang module map. The Swift one is used by the ExplicitSwiftModuleLoader, as before, and the Clang one is only used to populate the ClangArgs with the requried -fmodule-... flags and discarded.

[artemcm]

@allevato I only now noticed that this format collated Swift and Clang module details, when they share a name. I would like to separate them to have an entry per-module. This way the ExplicitModuleLoader doesn't need to filter out Clang-only entries and it generally seems a bit cleaner to have an individual entry correspond to an individual entry.

[artemcm]

@swift-ci test

[allevato]

Out of curiosity, why was the old behavior problematic? It seems like it should be fine if there's just one entry with a particular name in the list. Was some other tool like the dependency scanner writing the separate Swift/Clang entries instead?

[allevato]

Just saw your other comment while I was reading over the PR. For my particular use case it's marginally less attractive to have the entries separated due to the way they'll be generated (we use a single data structure to represent Swift and Clang modules together, and the structure before this PR lets us write out all the fields at the same time). But, I can make this work, so I don't have a strong opinion here if it makes something else in your tooling easier.

[artemcm]

Out of curiosity, why was the old behavior problematic? It seems like it should be fine if there's just one entry with a particular name in the list. Was some other tool like the dependency scanner writing the separate Swift/Clang entries instead?

Yeah. I ran into this when adopting the Clang module entries in the driver, which generates and specifies these module maps with a per-dependency entry, because the dependency scanner produces per-dependency entries. (Such entries ended up overwriting each other if they had the same name) I could teach it to detect and collate dependencies with the same name into one entry, but thought that this approach would be a bit more explicit.

[allevato]

It sounds like our dependency managers do the exact opposite thing, then 🙂 In this case, me iterating over the dependencies twice (once to emit the Swift entries and once for the Clang entries) is probably easier than you having to collate things together before writing, so I'm ok with this.

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test

[artemcm]

@swift-ci test Windows platform

[artemcm]

@swift-ci test