Author’s note: This article was created with substantial AI assistance.

mbun (an experimental project that rewrites the Bun runtime in C++26 and C++ modules) was originally built using the custom mcpp toolchain. This migration introduces a Bazel 9 build on top of baseline 5a901d7 to test Bazel’s support for C++20 modules. Previously, when testing modules, the module version of async_simple was the only available open-source project suitable for testing. mbun itself is a native modules project (with 98 modules), making it an ideal test case for Bazel and Clang’s module support. The mcpp build system has not been removed; both systems coexist during the migration. The BUILD.bazel files retain comments mapping them to the mcpp manifests (for example, src/BUILD.bazel maps each item to [targets.mbun] / [dependencies] in mcpp.toml).

The complete code is available at https://github.com/PikachuHyA/mbun/tree/bazel_build_mbun_opensource_20260805.

Large C++ projects often spend a surprising amount of time repeatedly parsing the same third-party headers. Header-only and template-heavy libraries make this even worse: every translation unit pays the cost again.

C++20 Modules provide a way out, but fully migrating a large codebase from #include to import is rarely realistic. This article describes a more incremental approach: use Clang module maps to translate selected #include directives into module imports during the build, while keeping application source code unchanged.

Recently, it was reported that C++20 module interface files generate no code coverage data. Upon investigating, I discovered that this is due to an instrumentation file that only accounts for explicitly instrumented files. If a file is not listed, its coverage data is skipped. For more details, refer to CoverageOutputGenerator–Main.java#L151-L155.

To address this, I’ve created a patch to include module interfaces in the instrumentation file. Below is the fix: