Description: The newly introduced -fmodules-driver mode enables explicit module builds directly from Clang’s driver, supporting both Clang modules discovered via module map files and C++20 named modules. Currently, these modules are precompiled from scratch on every invocation because the modules driver does not provide any caching. This is especially costly for large modules (e.g., the standard library modules), adding substantial overhead to each compilation.
This project aims to add compilation-job-level caching across the entire modules-driver build graph to enable incremental compilation. Using the dependency-scan results, the driver can track header and module dependencies for each input and determine which jobs must be rebuilt and which can be safely reused from a cache.
Expected outcomes: On repeated compilations, the modules driver should only execute compile jobs that are affected by changed or newly introduced inputs. All other unaffected jobs should be reused from the cache. If multiple Clang instances run simultaneously, the cache must remain correct and safe under concurrent access
Required skills: Intermediate knowledge of C++; familiarity with how C++ code is built. Familiarity with C++20 modules/Clang modules is an asset, but not required.
Hi @naveen-seth ,
This project interests me.
I have intermediate knowledge of C++ and how C++ is built.
I also have basic knowledge of incremental builds. I had built and used an incremental build of clang and lld from source for going through the Kaleidoscope Tutorial.
Could you please suggest me a good first issue or area to start contributing?
For first contributions, issues labeled good first issue are a great place to start (LLVM contributing guide). Crashes are also often good first fixes, so issues tagged crash-on-valid or crash-on-invalid are also worth a look.
I’ll additionally post more context and references to the relevant parts of the codebase for the proposals later this month, once the -fmodules-driver feature has fully landed.
I recently fixed and got merged a crash-on-invalid issue in clang frontend.
I would like to start working on issues that are more closely related to your proposed GSoC project, especially around the -fmodules-driver work. Are there specific components, files, or issue labels you would recommend that I look at or contribute to while waiting for additional context you mentioned?
As part of this project, you will be working with the driver (clang/lib/Driver/Driver.cpp) and the dependency-scanning library (clang/lib/DependencyScanning/). For the proposal, it would be helpful to become generally familiar with their high-level functionality.
Right now, I can only point broadly to these areas, but once the code has landed, I will share the relevant references and more specific details.
This open PR #152770 will add the majority of the -fmodules-driver implementation. I had hoped to land this before posting, but it is expected to be merged soon.
Initially, we had hoped to add incremental build support using the LLVM CAS ([1], [2]) . However, some of the required components will likely only land later this year. Still, it may be nice to be aware of this work, even though the proposals should not build on LLVM CAS.
hello @naveen-seth,
thanks in advance .
I’ve just discovered the project, and it really into my mind to contribute to it.
I worked on different projects in C++, to embedded systems, Ros2_control, and computer vision in for edge devices. in addition to that, I competed, and solved programming problems at icpc, ieeextereme, and on platforms like codeforces and leetcode.
Sorry for my late….I wanna know the last updates being done to the project, and the plan proposed till now .
Hi @HatemHassan, thanks for your interest in the project!
There haven’t been any new updates since my last message.
If anyone would like me to review their proposal draft, feel free to email me at naveen.hanig@outlook.com and, if possible, also send me a message on the forum that you did.
I’ve been exploring the modules-driver caching project and found it really interesting, especially the idea of enabling incremental compilation using dependency tracking.
From what I understand, the current -fmodules-driver mode recompiles modules on every invocation due to lack of caching, which adds significant overhead.
I had a couple of questions:
How are module dependencies currently represented in dependency-scan results?
Are there existing caching mechanisms in Clang that could be extended here?
I’ve been working on parallel computing and performance-focused projects using C++ (OpenMP/MPI), and I’m interested in contributing.
Could you guide me on how to get started with the codebase?
Hi @naveen-seth ,
I’ve sent you an e-mail with subject “[GSoC 2026] Draft Proposal for “Incremental build support for the modules driver” “.
Could you please check it?
Thank you.
Hi @naveen-seth , I’ve sent you an email with the subject “GSoC 2026 Proposal Draft – Modules Driver Incremental Build Support” , could you pls check it and provide some feedback on it.
Thank you for your time
I’ve sent an email titled GSoC Proposal: Incremental Compilation for Clang’s Modules Driver, I’d appreciate any feedback you could give on my proposal.
Hi @naveen-seth,
I’m Uzair, a CS student. I just submitted my proposal for this project and sent it to your email as well.
I’ve interned at JPMorgan and Snap, where caching, dependency tracking, and concurrent access were things I dealt with directly. At JPMorgan I built Kafka consumers where offset management and partition strategies had to guarantee correctness across distributed brokers. At Snap I worked on event-driven content delivery where cache invalidation under concurrent writes was the main challenge. I’m also doing HPC research at Ohio State on C/C++ multi-threaded pipelines and I have a merged PR on QuantLib from a few weeks of code review with the maintainer.
Your pointers to ModulesDriver.cpp, LockFileManager, and ModuleCache.cpp in this thread were really useful for putting the proposal together. I based the concurrent access approach on the implicit module build patterns you mentioned.
Happy to get feedback on the proposal or talk through the approach!
I’ve sent my final proposal in the same e-mail thread of ‘[GSoC 2026] Draft Proposal for “Incremental build support for the modules driver” ‘
Could you please check it?
)