If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
Details
Diff Detail
Event Timeline
Your change and your documentation don't match. The difference is the behavior in the case where a module is not provided explicitly but is found in the module cache; your documentation says this is invalid but your code accepts it. I think the more principled approach would be to do as your documentation suggests: require all modules to be provided via explicitly-specified .pcm files, and never look in the module cache.
I would also like to bikeshed the flag name; -fno-implicit-modules seems like a better name to me. I'd also suggest renaming -fno-modules-implicit-maps to -fno-implicit-module-maps because "module map" is the term of art here, and it doesn't make sense to split this term. Grouping these flags under -fmodules seems secondary to having them make sense as flag names.
docs/Modules.rst | ||
---|---|---|
213–214 | Please also add documentation for -fmodule-file if you're going to reference it from here. =) | |
include/clang/Basic/DiagnosticCommonKinds.td | ||
84–85 | This seems like the wrong message to produce -- the problem here is that the module *was* found in some loaded module map file, but a prebuilt form of that module was not provided. |
Please add test coverage showing that we can use explicitly-specified modules via -fmodule-file=, and that we can't use implicitly-build modules that are in the cache.
lib/Frontend/CompilerInstance.cpp | ||
---|---|---|
1364–1368 | This will also reject modules loaded via -fmodule-file=. | |
1376–1382 | The check should go somewhere around here, after we've determined whether the user gave us a file containing this module. if (!Explicit && !ImplicitModules). |
include/clang/Basic/DiagnosticCommonKinds.td | ||
---|---|---|
84–86 | This diagnostic suggests that it'd be OK if the module didn't need to be compiled. Maybe something like "module '%0' is needed but has not been provided, and implicit use of module files is disabled"? | |
include/clang/Driver/Options.td | ||
706–711 | It doesn't look like you're forwarding these from the driver to the frontend (and you have no test coverage for the driver flags). The same appears to be true of -fmodules-implicit-maps, which currently doesn't seem to work as a driver option... Also, it's conventional to only provide one of the -fblah and -fno-blah options as a -cc1 option (the non-default flag only); see OPT_fmodules_decluse for an example. | |
test/Modules/no-implicit-builds.cpp | ||
4–7 | Do you need the -fmodule-name= in these tests? It doesn't seem relevant to the subject matter. If you can remove that, can you also remove a.modulemap entirely and directly use b.modulemap here? | |
27–28 | Is this CHECK useful? |
docs/Modules.rst | ||
---|---|---|
216 | -fmodule-file=<FILE> or similar would be clearer | |
lib/Driver/Tools.cpp | ||
3928–3933 | Maybe hold back on adding driver support for this flag until after it's renamed? | |
test/Modules/Inputs/no-implicit-builds/a.modulemap | ||
1–5 ↗ | (On Diff #20075) | This file appears to be unused. |
test/Modules/no-implicit-builds.cpp | ||
16–17 | Add -Rmodule-build to the command line for safety / clarity, given this. |
Please also add documentation for -fmodule-file if you're going to reference it from here. =)