================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
