5 Commits

Author SHA1 Message Date
Chuanqi Xu
e22fa1d4c6 [C++20] [Modules] Emit a warning if the we load the modules by implicit generated path
A step to address https://github.com/llvm/llvm-project/issues/62707.

It is not user friendly enough to drop the implicitly generated path
directly. Let's emit the warning first and drop it in the next version.
2023-05-17 17:53:36 +08:00
Chuanqi Xu
5783363681 [C++20] [Modules] Deprecate to load C++20 Modules eagerly
Close https://github.com/llvm/llvm-project/issues/60824

The form -fmodule-file=<path-to-BMI> will load modules eagerly and the
form -fmodule-file=<module-name>=<path-to-BMI> will load modules lazily.
The inconsistency adds many additional burdens to the implementations.
And the inconsistency looks not helpful and necessary neither. So I want
to deprecate the form -fmodule-file=<path-to-BMI> for named modules.
This is pretty helpful for us (the developers).

Does this change make any regression from the perspective of the users?

To be honest, yes. But I think such regression is acceptable. Here is
the example:

```
// M.cppm
export module M;
export int m = 5;

// N.cpp
// import M; // woops, we forgot to import M.
int n = m;
```

In the original version, the compiler can diagnose the users to import
`M` since the compiler have already imported M. But in the later style,
the compiler can only say "unknown identifier `m`".

But I think such regression doesn't make a deal since it only works if
the user put `-fmodule-file=M.pcm` in the command line. But how can the
user put `-fmodule-file=M.pcm` in the command line without `import M;`?
Especially currently such options are generated by build systems. And
the build systems will only generate the command line from the source
file.

So I think this change is pretty pretty helpful for developers and
almost innocent for users and we should accept this one.

I'll add the release notes and edit the document after we land this.

Differential Revision: https://reviews.llvm.org/D144707
2023-03-03 14:25:33 +08:00
Chuanqi Xu
9c04851cf5 [C++20] [Module] Support reachable definition initially/partially
This patch introduces a new kind of ModuleOwnershipKind as
ReachableWhenImported. This intended the status for reachable described
at: https://eel.is/c++draft/module.reach#3.

Note that this patch is not intended to support all semantics about
reachable semantics. For example, this patch didn't implement discarded
declarations in GMF. (https://eel.is/c++draft/module.global.frag#3).

This fixes: https://bugs.llvm.org/show_bug.cgi?id=52281 and
https://godbolt.org/z/81f3ocjfW.

Reviewed By: rsmith, iains

Differential Revision: https://reviews.llvm.org/D113545
2022-06-29 12:48:48 +08:00
Chuanqi Xu
7a541406b5 Revert "[C++20] [Modules] Implement Reachable initiallly"
This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.

The previous commit don't contain additional information, which is bad.
2022-06-29 12:43:26 +08:00
Chuanqi Xu
a223ba0a69 [C++20] [Modules] Implement Reachable initiallly 2022-06-29 12:32:31 +08:00