rsmith added a comment. In D125773#3525127 <https://reviews.llvm.org/D125773#3525127>, @ilya-biryukov wrote:
> It looks like this particular change actually breaks standard compatibility > as we also use the same parsing action and don't build a module separately on > `import`. > > [module.import]p5 > A module-import-declaration that specifies a header-name H imports a > synthesized header unit, which is a > translation unit formed by applying phases 1 to 7 of translation (5.2) to > the source file or header nominated > by H, which shall not contain a module-declaration. For the record, the intention is that (with local submodule visibility enabled) we behave "as if" we preprocessed separately, even if we do so using the same parsing action: we store various parts of the preprocessor state (most notably, the defined macros map) per-module, so that when we switch modules, we get the same preprocessing behavior as if we'd started from a clean slate. Fundamentally, Clang's model is that a single `ASTContext` and a single preprocessing action can cover multiple translation units, and that includes the possibility that a single preprocessor or `Sema` object can process multiple translation units, and we make this work by tracking which macros and declarations and similar should be visible where, based on which modules are currently imported. This is intended to be a conforming strategy for implementing C++20 header units. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125773/new/ https://reviews.llvm.org/D125773 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
