[PATCH] D23125: Modules: add command line option to support loading prebuilt modules on demand, without parsing any module map

[Bruno Cardoso Lopes via cfe-commits]

bruno added inline comments.

================
Comment at: lib/Frontend/CompilerInstance.cpp:1438-1450
@@ -1437,3 +1437,15 @@
     // Search for a module with the given name.
     Module = PP->getHeaderSearchInfo().lookupModule(ModuleName);
-    if (!Module) {
+    HeaderSearchOptions &HSOpts =
+        PP->getHeaderSearchInfo().getHeaderSearchOpts();
+
+    std::string ModuleFileName;
+    bool LoadFromPrebuiltModulePath = false;
+    if (Module) {
+      ModuleFileName = PP->getHeaderSearchInfo().getModuleFileName(Module);
+    } else if (!HSOpts.PrebuiltModulePath.empty()) {
+      // Try to load the module from the prebuilt module path.
+      ModuleFileName =
+          PP->getHeaderSearchInfo().getModuleFileName(ModuleName, "", true);
+      LoadFromPrebuiltModulePath = true;
+    } else {
----------------
manmanren wrote:
> rsmith wrote:
> > It looks like the logic here is:
> > 
> >  * if we found the module in a module map, then look for it in the module cache
> >  * otherwise, if we have a prebuilt module path, then look for it there
> >  * otherwise, error
> > 
> > I think that may be surprising; if I explicitly load a module map, perhaps via `-fmodule-map-file=`, and supply a prebuilt form of that module in the prebuilt modules path, I'd expect my prebuilt form to still be used.
> > 
> > Perhaps instead we could first search the prebuilt module path for an existing .pcm file, and if that fails and we have a `Module` then look for it in the module cache?
> I was wondering about the priority of loading from prebuilt module path vs. loading from module cache. Your suggestion makes sense.
+1 to Richard's suggestion here.

I wonder about the workflow on generating such modules. Suppose I want to build some modules to re-use later with -fprebuilt-module-path=. RIght now, we get a module cache with hash in the names unless we disable hash computation via cc1 option -fdisable-module-hash. Should we assume that the user will have to copy out the cache dir and rename the modules OR that it will use -fdisable-module-hash instead? Should this option also try to read out modules with a hash in the name? Should we promote -fdisable-module-hash to a driver option as well?

@Manman, do you have any workflow in mind? @Richard, do you have any feedback in this respect?

In the crash reproducer we often have to rebuild the modules when running the script in a different machine because of the paths used to hash the modules, it would be nice (depending on the resulting design) if the crash reproducer could use -fprebuilt-module-path in order to try to re-use the pre-built modules resulting from the crash. 


https://reviews.llvm.org/D23125