[clang] [clang][Dependency Scanning] Report Exported Modules during Scanning (PR #137421)

[Qiongsi Wu via cfe-commits]

================
@@ -183,7 +192,7 @@ struct ModuleDeps {
   ///
   /// This may include modules with a different context hash when it can be
   /// determined that the differences are benign for this compilation.
-  std::vector<ModuleID> ClangModuleDeps;
+  std::vector<ExtendedModuleID> ClangModuleDeps;
----------------
qiongsiwu wrote:

> Why is whether a module is Exported encoded here instead of directly as an attribute in ModuleDeps?

I chose this implementation for two reasons (in addition to @Bigcheese's suggestion). 

1. Easy to use - I think doing it this way offers better ergonomics for the intended use [here](https://github.com/swiftlang/swift/blame/3437609eb580c24776979b97663bdb81383bee04/lib/ClangImporter/ClangModuleDependencyScanner.cpp#L300). If I understand it correctly, Swift can simply do `moduleName.Exported` where it is intended. 
2. Efficiency - I did not find a good way to store what modules are exported as an attribute in `ModuleDeps` after a few tries. I can store a list of `ModuleID`s, but that duplicates a subset of `ClangModuleDeps`. Or I can store an array of indices (or pointers) into `ClangModuleDeps`, and that can run into the potential issue where we update `ClangModuleDeps` (e.g. sorting it), and the pointers in the array become invalid. 

> Is it that clients need to know all the modules that export a given module?

No I don't think that is the use case. I think the use case is that the client wants to know if a particular dependency of a module is exported. 

https://github.com/llvm/llvm-project/pull/137421