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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
