[PATCH] D120540: [Driver] Enable to use C++20 modules standalone by -fcxx-modules

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D120540#3384644 <https://reviews.llvm.org/D120540#3384644>, @ChuanqiXu wrote:

> @rsmith told me that the ideal situation would combine C++20 modules and clang modules together in D113391 <https://reviews.llvm.org/D113391>

Maybe I understand something slightly different; that we should migrate to a situation where compiling C++ code //**with no other contradicting options**//, would produce C++20 modules.  Preferably, for most users that means no special options would be needed for the standardised modules.

> I think the most important thing here is to get in consensus for the module status. Here might be some helpful questions for the goal:
>
> - Should C++20 modules and Clang modules be exclusive from each other?
>   - If yes, we could take the idea ` -fmodules= {clang, c++20, none...} ` and forbid the combination of `-fmodules  -std=c++20`. And we could use variable `Modules` to indicate clang modules and `CPlusPlusModules` to indicate c++20 modules.
> - If no, it implies that we could use c++20 modules and clang modules together. So the combination of `-fmodules -std=c++20` or even `-fmodules -fcxxmodules` makes sense. It implies that we could use the grammar of clang module extension or c++20 modules. This is decision from D113391 <https://reviews.llvm.org/D113391>. Here are some further questions:

In my input, there was no intention to forbid `-fmodules  -std=c++20`,  quite the opposite (it would be OK).
I am suggesting that  the presence of `fmodules` on the command line would be a statement that the user wanted `clang modules` (and that would be perfectly OK in conjunction with C++20). 
... But that would switch off C++20 modules mode because there are incompatibilities at present (in particular it means treating headers differently - and possibly sub-module visibility).  There might come a time when clang modules are identical to C++20 ones, but I could imagine that would be some considerable time in the future - because end users would have to migrate.

> - Would it be very hard to implement or maintain?

once we have a firm plan for which things are allowed together it is not hard to maintain - what is hard to maintain is a situation in which we are not sure of exactly what we should be producing ...

> - We lack a variable to indicate clang modules only. Currently, we couldn't use `Modules` to indicate clang modules since `Modules` is true if we turned C++20 modules on. `Modules` indicate either clang module or c++20 module is enabled. Or we could think it means the common parts of the two features.

we could make such a variable easily - if the decision was made to do it (what could be a little harder is to separate out the modules command line options into mutually-exclusive groups).

> The most important technical question might be `Would it be very hard to implement or maintain?`. From my experience, I think it is implementable. But I **feel** it is not easy to maintain. We don't have the experience since C++20 modules are not in the state of maintaining now.
>
> I don't have strong opinions for the concrete decision. But I think it is very important to get in consensus. @iains @Bigcheese

In this processes, I am not a major stakeholder - just an interested party as a coder and user - the call is down to @rsmtih and @Bigcheese.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120540/new/

https://reviews.llvm.org/D120540