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 | ||
|---|---|---|
| 1363–1367 | This will also reject modules loaded via -fmodule-file=. | |
| 1375–1381 | 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 | ||
| 684–689 | 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 | ||
| 3912–3917 ↗ | (On Diff #20075) | Maybe hold back on adding driver support for this flag until after it's renamed? |
| test/Modules/Inputs/no-implicit-builds/a.modulemap | ||
| 2–6 | 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. | |
And one more whitespace cleanup.
| docs/Modules.rst | ||
|---|---|---|
| 216 | Done, using <file> to match <directory> above. | |
| lib/Driver/Tools.cpp | ||
| 3912–3917 ↗ | (On Diff #20075) | That is an excellent point, thx. |
| test/Modules/Inputs/no-implicit-builds/a.modulemap | ||
| 2–6 | Done. | |
| test/Modules/no-implicit-builds.cpp | ||
| 16–17 | Done. | |
Please also add documentation for -fmodule-file if you're going to reference it from here. =)