[all-commits] [llvm/llvm-project] af2d11: [C++20][Modules] Implement include translation.

[iains via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: af2d11b1d5c1508b506825df460656e0151cd3b0
      https://github.com/llvm/llvm-project/commit/af2d11b1d5c1508b506825df460656e0151cd3b0
  Author: Iain Sandoe <iain at sandoe.co.uk>
  Date:   2022-07-10 (Sun, 10 Jul 2022)

  Changed paths:
    M clang/include/clang/Lex/Preprocessor.h
    M clang/lib/Lex/PPDirectives.cpp
    M clang/lib/Lex/Preprocessor.cpp
    M clang/lib/Parse/Parser.cpp
    A clang/test/Modules/cxx20-include-translation.cpp

  Log Message:
  -----------
  [C++20][Modules] Implement include translation.

This addresses [cpp.include]/7

(when encountering #include header-name)

If the header identified by the header-name denotes an importable header, it
is implementation-defined whether the #include preprocessing directive is
instead replaced by an import directive.

In this implementation, include translation is performed _only_ for headers
in the Global Module fragment, so:
```
module;
 #include "will-be-translated.h" // IFF the header unit is available.

export module M;
 #include "will-not-be-translated.h" // even if the header unit is available
```
The reasoning is that, in general, includes in the module purview would not
be validly translatable (they would have to immediately follow the module
decl and without any other intervening decls).  Otherwise that would violate
the rules on contiguous import directives.

This would be quite complex to track in the preprocessor, and for relatively
little gain (the user can 'import "will-not-be-translated.h";' instead.)

TODO: This is one area where it becomes increasingly difficult to disambiguate
clang modules in C++ from C++ standard modules.  That needs to be addressed in
both the driver and the FE.

Differential Revision: https://reviews.llvm.org/D128981