[C++20] [Modules] Ambiguousness of owning modules

[ChuanqiXu9]

I try to summarize the concern about the compatibilities of named modules and PCH and header like modules (clang modules and header units). I try to use this page to describe the meta issue even if there is no such reports now.

Background

In short, due to named modules bring new semantics, we need to change the following questions in a lot of places:

• If a declaration belongs to a global module fragment.
• If a declaration belongs to a global module fragment of other translation units than the current one we're handling.
• If a declaration belongs to a named module. If yes, we need to get its name. And if it is the one we're parsing.

For the first question, now we use D->getOwningModule()->isExplicitGlobalModule() to get the answer. It works fine. But if we meet PCH and header like modules. It just doesn't work. For example,

module;
#include "header.h" // replaced by clang header modules
export module m;
...

In this example, if #include "header.h" got replaced by clang header modules, the returned module will be the clang header module instead of the global module fragment we want. Then, mismatch happens.

I think the key point here is that we abused the clang::Module class. I think, ideally, there will be two kinds of modules, one is in the serialization level like clang::Module and another one should be used at semantical level. But we don't have that one now and we're using clang::Module to do that. If we had that, we can always use the semantical level modules for questions I raised.

So it looks like we probably have to do some large scale refactors.

Some ideas

From the perspective of the specification, there are only 2 kinds of modules in C++: the global module and named modules. Then I thought if we can treat all header like modules as the global module to workaround? It is fine for header units but not for clang modules (or it is not well defined).

For example,

export module a;
#include "my_headers" // replaced by clang header modules

If #include "my_headers" got replaced by clang header modules, then should the declarations in my_headers be treated as if in named modules? Or should we treat them as in global module just like header units?

PCH

PCH looks more odd with named modules. For example, for

module;
#include "header.h"
export module m;
...

if we include-pch for header.h, as far I understood, it is like doing:

#include-pch "header.h"
module;
#include "header.h"
export module m;
...

But ... it is invalid to include things before module;! So it looks more weird to me. And I don't know what happens if we write the module unit with PCH included precisely, I feel it is a dark corner.

---

Maybe there are other problems. And I don't have a very clear idea for the refactoring I said above. But it should be good to make such dark corners more explicit and track them in one place.

CC: @dwblaikie @mizvekov @zygoloid @Bigcheese @jansvoboda11 @vgvassilev

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Chuanqi Xu (ChuanqiXu9)

I try to summarize the concern about the compatibilities of named modules and PCH and header like modules (clang modules and header units). I try to use this page to describe the meta issue even if there is no such reports now.

Background

In short, due to named modules bring new semantics, we need to change the following questions in a lot of places:

• If a declaration belongs to a global module fragment.
• If a declaration belongs to a global module fragment of other translation units than the current one we're handling.
• If a declaration belongs to a named module. If yes, we need to get its name. And if it is the one we're parsing.

For the first question, now we use D->getOwningModule()->isExplicitGlobalModule() to get the answer. It works fine. But if we meet PCH and header like modules. It just doesn't work. For example,

module;
#include "header.h" // replaced by clang header modules
export module m;
...

In this example, if #include "header.h" got replaced by clang header modules, the returned module will be the clang header module instead of the global module fragment we want. Then, mismatch happens.

I think the key point here is that we abused the clang::Module class. I think, ideally, there will be two kinds of modules, one is in the serialization level like clang::Module and another one should be used at semantical level. But we don't have that one now and we're using clang::Module to do that. If we had that, we can always use the semantical level modules for questions I raised.

So it looks like we probably have to do some large scale refactors.

Some ideas

From the perspective of the specification, there are only 2 kinds of modules in C++: the global module and named modules. Then I thought if we can treat all header like modules as the global module to workaround? It is fine for header units but not for clang modules (or it is not well defined).

For example,

export module a;
#include "my_headers" // replaced by clang header modules

If #include "my_headers" got replaced by clang header modules, then should the declarations in my_headers be treated as if in named modules? Or should we treat them as in global module just like header units?

PCH

PCH looks more odd with named modules. For example, for

module;
#include "header.h"
export module m;
...

if we include-pch for header.h, as far I understood, it is like doing:

#include-pch "header.h"
module;
#include "header.h"
export module m;
...

But ... it is invalid to include things before module;! So it looks more weird to me. And I don't know what happens if we write the module unit with PCH included precisely, I feel it is a dark corner.

---

Maybe there are other problems. And I don't have a very clear idea for the refactoring I said above. But it should be good to make such dark corners more explicit and track them in one place.

CC: @dwblaikie @mizvekov @zygoloid @Bigcheese @jansvoboda11 @vgvassilev