[PATCH] D121098: [C++20][Modules][HU 4/5] Handle pre-processed header units.

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D121098#3384590 <https://reviews.llvm.org/D121098#3384590>, @ChuanqiXu wrote:

> In D121098#3383835 <https://reviews.llvm.org/D121098#3383835>, @iains wrote:
>
>>> I am a little bit confused for the intuition. Couldn't we just import the pre-processed header? What's the problem? Could you elaborate on this?
>>
>> We cannot import a pre-processed file; the preprocessed file is still source code, not a CMI.
>
> But if I understand correctly, we are able to import a pre-processed file as a header unit. Couldn't we?
>
> For example:
>
>   // cc -E foo.h > foo.preprocessed
>   import "foo.preprocessed"
>   ...
>
> Is this not acceptable?
>
>> In addition, the pre-processor output for a header unit requires further pre-processing on read.
>> This is because a header unit actually preserves some of the pre-processor information [macro definitions] (which would normally be discarded after phase 4).
>>
>> Header units are identifiable by a name (in common with GCC, we make the name == the path by which the header is specified) -- that name is intentionally not a  legal named module name (neither is it, in general, a legal identifier).
>
> So it doesn't eliminate my confusion. I guess there is some workflows that we need to import a preprocessed header as header unit (and we need to find the position of original file). Or in what circumstances, do we need to import a pre-processed header as header unit?

A pre-processed header unit can only be used to build that header unit - just like a pre-processed c++ source is used to build an object for the original source file.

In this code, we are not considering importing the HU into another module - that can only be done once the HU is built as a CMI.

The pre-processed output has two immediate uses I could see:
 (1) traditionally, it can be helpful in debugging and problem reporting [since the included headers are flattened]
 (2) because we will have processed the directives, it might be useful for scanners that want to determine remaining dependencies.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121098