@@ -1030,8 +1030,38 @@ ClangImporter::createClangInvocation(ClangImporter *importer,
1030
1030
&tempDiagClient,
1031
1031
/* owned*/ false );
1032
1032
1033
- return clang::createInvocationFromCommandLine (invocationArgs, tempClangDiags,
1034
- nullptr , false , CC1Args);
1033
+ auto CI = clang::createInvocationFromCommandLine (
1034
+ invocationArgs, tempClangDiags, nullptr , false , CC1Args);
1035
+
1036
+ if (!CI) {
1037
+ return CI;
1038
+ }
1039
+
1040
+ // FIXME: clang fails to generate a module if there is a `-fmodule-map-file`
1041
+ // argument pointing to a missing file.
1042
+ // Such missing module files occur frequently in SourceKit. If the files are
1043
+ // missing, SourceKit fails to build SwiftShims (which wouldn't have required
1044
+ // the missing module file), thus fails to load the stdlib and hence looses
1045
+ // all semantic functionality.
1046
+ // To work around this issue, drop all `-fmodule-map-file` arguments pointing
1047
+ // to missing files and report the error that clang would throw manually.
1048
+ // rdar://77516546 is tracking that the clang importer should be more
1049
+ // resilient and provide a module even if there were building it.
1050
+ auto VFS = clang::createVFSFromCompilerInvocation (
1051
+ *CI, *tempClangDiags,
1052
+ importer->Impl .SwiftContext .SourceMgr .getFileSystem ());
1053
+ std::vector<std::string> FilteredModuleMapFiles;
1054
+ for (auto ModuleMapFile : CI->getFrontendOpts ().ModuleMapFiles ) {
1055
+ if (VFS->exists (ModuleMapFile)) {
1056
+ FilteredModuleMapFiles.push_back (ModuleMapFile);
1057
+ } else {
1058
+ importer->Impl .SwiftContext .Diags .diagnose (
1059
+ SourceLoc (), diag::module_map_not_found, ModuleMapFile);
1060
+ }
1061
+ }
1062
+ CI->getFrontendOpts ().ModuleMapFiles = FilteredModuleMapFiles;
1063
+
1064
+ return CI;
1035
1065
}
1036
1066
1037
1067
std::unique_ptr<ClangImporter>
0 commit comments