Now the implementation would accept following code:
```
//--- impl.cppm
module M:impl;
class A {};
//--- M.cppm
export module M;
import :impl;
//--- Use.cpp
import M;
void test() {
A a; // Expected error. A is not visible here.
}
```
which is clearly wrong. The root cause is the implementation of
`isInCurrentModule` would return true if the module is a partition! So
in the above example, although Use.cpp is not a module unit,
`isInCurrentModule ` would still return true when the compiler tries to
see if the owning module of `A` is the current module. I believe this is
an oversight. This patch tries to fix this problem.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D123837
Implementation partitions bring two extra cases where we have
visibility of module-private data.
1) When we import a module implementation partition.
2) When a partition implementation imports the primary module intertace.
We maintain a record of direct imports into the current module since
partition decls from direct imports (but not trasitive ones) are visible.
The rules on decl-reachability are much more relaxed (with the standard
giving permission for an implementation to load dependent modules and for
the decls there to be reachable, but not visible).
Differential Revision: https://reviews.llvm.org/D118599
Partition implementations are special, they generate a CMI, but it
does not have an 'export' line, and we cannot export anything from the
it [that is it can only make decls available to other members of the
owning module, not to importers of that].
Add initial testcases for partition handling, derived from the examples in
Section 10 of the C++20 standard, which identifies what should be accepted
and/or rejected.
Differential Revision: https://reviews.llvm.org/D118587
Chuanqi Xu