Skip to content

Support Using Clang Module Map to Avoid mixing #include and import pr…#777

Open
PikachuHyA wants to merge 1 commit into
bazelbuild:mainfrom
PikachuHyA:upstream_support_modulemap
Open

Support Using Clang Module Map to Avoid mixing #include and import pr…#777
PikachuHyA wants to merge 1 commit into
bazelbuild:mainfrom
PikachuHyA:upstream_support_modulemap

Conversation

@PikachuHyA

Copy link
Copy Markdown
Contributor

…oblems

Motivation

We are refactoring our legacy code to enable C++20 Modules. With this approach, we do not need to change the actual business code, or only need to make very small changes. We only need to add a .modulemap file to get the benefits of C++20 Modules.

Summary

Adds a new module_header_maps attribute to cc_library and cc_binary so targets can use Clang header module maps (.modulemap + -fmodule-map-file) alongside C++20 named modules (module_interfaces).

This addresses the common case where legacy #include and import must coexist in the same translation unit: Clang can treat headers as part of a named module when a module map is provided, without requiring every header to be rewritten as a module interface. see https://clang.llvm.org/docs/StandardCPlusPlusModules.html#using-clang-module-map-to-avoid-mixing-include-and-import-problems

New attribute

  • module_header_maps: dict mapping module name → .modulemap label (via string_keyed_label_dict)
  • Requires --experimental_cpp_modules and the toolchain cpp_modules feature (same as module_interfaces)

Compile behavior

When module_header_maps is set on a target:

  1. Per-source DDI scanning and per-source generate-modmap are skipped for .cc files on that target.
  2. A single target-level modmap is produced by reusing the existing generate-modmap / CppGenModmap pipeline:
    • Synthetic DDI JSON lists all module names from the dict.
    • One shared modmap + modmap.input is generated for all .cc sources.
  3. .modulemap files are passed as compile additional_compilation_inputs and emitted via a new toolchain feature cpp_module_header_map_files as -fmodule-map-file=... (Linux Clang toolchain only).

Intentional v1 limitations

To simplify the implementation

  • module_header_maps is not propagated through CcCompilationContext; each target that compiles .cc and needs header maps must declare them explicitly (same pattern as early module_interfaces usage).
  • No per-.cc dependency analysis: the shared modmap includes all modules listed in the dict for every .cc on the target.
  • cpp_module_header_map_files is registered only on the Unix/Linux toolchain config (not Windows/macOS yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant