[PATCH] D134267: [C++] [Modules] Support one phase compilation model for named modules

Iain Sandoe via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 13 01:13:09 PDT 2022


iains added a comment.

In D134267#3854980 <https://reviews.llvm.org/D134267#3854980>, @ChuanqiXu wrote:

> In D134267#3852136 <https://reviews.llvm.org/D134267#3852136>, @boris wrote:
>
>>> For example, my experimental support for P1689 <https://reviews.llvm.org/P1689> is at: [...]. The implementation looks relatively trivial to me. The simplicity is pretty important.



>> 2. I haven't looked at the code, but there are some complex problems in this area as highlighted by this MSVC bug: https://developercommunity.visualstudio.com/t/scanDependencies-does-not-take-into-acc/10029154 I believe you may have it easier because reportedly Richard & friends have already implemented the necessary header import isolation semantics.
>
> Yeah, it looks like the header unit brings new complexity. And my demo only works for named modules. I need to reconsider it.

Header Units are "special", they defeat automatic processing in my view.

- The compiler cannot determine that a source is a HU (from the header source); it has to be told.
- A build system can determine that a source **depends** on a header (of course, that is already done for years), however, it is not at all clear that the build system is able to determine if that dependent header is an "importable header" and therefore suitable for building as a HU.  Maybe the build system folks have some ideas, of course (and a sub-set of headers are pre-defined as importable).

So, I suspect, that we will be expecting (at least in the short to medium term) the user's project to define which headers should be converted to HUs;  we already have specific driver options to help with the actual production.


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

https://reviews.llvm.org/D134267



More information about the cfe-commits mailing list