[all-commits] [llvm/llvm-project] 9dc0b1: [clang][deps] Report module map describing compile...

[Jan Svoboda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9dc0b1674841243110f95cdc9c9d97bcf30c1544
      https://github.com/llvm/llvm-project/commit/9dc0b1674841243110f95cdc9c9d97bcf30c1544
  Author: Jan Svoboda <jan_svoboda at apple.com>
  Date:   2022-09-22 (Thu, 22 Sep 2022)

  Changed paths:
    M clang/include/clang/Basic/LangOptions.h
    M clang/include/clang/Lex/Preprocessor.h
    M clang/lib/Lex/Preprocessor.cpp
    M clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
    A clang/test/ClangScanDeps/modules-header-sharing.m
    R compiler-rt/test/orc/TestCases/Darwin/x86-64/Inputs/dlopen-dlclose-x2.s

  Log Message:
  -----------
  [clang][deps] Report module map describing compiled module

This patch fixes compilation failure with explicit modules caused by scanner not reporting the module map describing the module whose implementation is being compiled.

Below is a breakdown of the attached test case. Note the VFS that makes frameworks "A" and "B" share the same header "shared/H.h".

In non-modular build, Clang skips the last import, since the "shared/H.h" header has already been included.

During scan (or implicit build), the compiler handles "tu.m" as follows:
  * `@import B` imports module "B", as expected,
  * `#import <A/H.h>` is resolved textually (due to `-fmodule-name=A`) to "shared/H.h" (due to the VFS remapping),
  * `#import <B/H.h>` is resolved to import module "A_Private", since the header "shared/H.h" is already known to be part of that module, and the import is skipped.
In the end, the only modular dependency of the TU is "B".

In explicit modular build without `-fmodule-name=A`, TU does depend on module "A_Private" properly, not just textually. Clang therefore builds & loads its PCM, and knows to ignore the last import, since "shared/H.h" is known to be part of "A_Private".

But with current scanner behavior and `-fmodule-name=A` present, the last import fails during explicit build. Clang doesn't know about "A_Private" (it's included textually) and tries to import "B_Private" instead, which it doesn't know about either (the scanner correctly didn't report it as dependency). This is fixed by reporting the module map describing "A" and matching the semantics of implicit build.

Reviewed By: Bigcheese

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