================ Comment at: include/clang/Basic/LangOptions.def:96 @@ -95,2 +95,3 @@ LANGOPT(Modules , 1, 0, "modules extension to C") +LANGOPT(Modules_noload , 1, 0, "disable loading of modules") LANGOPT(Optimize , 1, 0, "__OPTIMIZE__ predefined macro") ---------------- I'd rather have these options build constructively, rather than destructively, because it's hard to remember to check "Modules && !Modules_noload". I suggest you divide it as:
- ModuleMaps: read module maps and use them to somehow understand the structure of library headers - Modules: full support for modules, which implies ModuleMaps Moreover, I think ModuleMaps belongs in HeaderSearchOptions, because it's really about the headers. In fact, one could imagine a future panacea where we have Modules && !ModuleMaps, because headers have become irrelevant :) ================ Comment at: include/clang/Driver/Options.td:520 @@ -519,1 +519,3 @@ HelpText<"Enable the 'modules' language feature">; +def fmodules_noload : Flag <["-"], "fmodules-noload">, Group<f_Group>, Flags<[NoForward,CC1Option]>, + HelpText<"Disable the loading of 'modules'">; ---------------- How about -fmodule-maps? Also, it doesn't look like this is getting passed through the driver. Make sure you check whether "clang -fmodules-noload -###" passes -fmodules-noload through to the -cc1 invocation. ================ Comment at: include/clang/Basic/DiagnosticCommonKinds.td:81 @@ -80,2 +80,3 @@ def err_module_not_built : Error<"could not build module '%0'">, DefaultFatal; +def err_module_load_off : Error<"module loading is off '%0'">, DefaultFatal; def err_module_cycle : Error<"cyclic dependency in module '%0': %1">, ---------------- I don't think we need this diagnostic; see below. http://llvm-reviews.chandlerc.com/D963 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
