[Clang] C++ Modules: Template function body changes don't trigger recompilation

[RedNicStone]

Changes to template function bodies in C++ modules don't trigger recompilation of dependent code, allowing invalid code to "compile" and run.

This issue is detrimental to the module workflow and could pose some security risks. Specifically,

• Builds silently succeed instead of an expected fail
• This issue persists across full rebuilds, since module caches are located in ~/.cache/ccache (this took me a very long time to figure out)
• It makes debugging template code de-facto impossible
• Any form of static warnings, assertions or other compile time failures may pass compilation even though they should not

Steps to Reproduce:

1. Create interface module module.ixx

export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    // static_assert(0);  // Should fail at compile time
    // *(volatile char*)nullptr = 0;  // Should fail at run time
    // We will make the above statements run and compile later, but for now we need to make it compile successfully once

    return i;
}

2. Create source file test.cpp

import somemodule;

int main() {
    return test<int>();
}

3. Build and run application

clang++ -std=gnu++23 -x c++-module -fmodule-output=somemodule.pcm -c module.ixx -o module.o
clang++ -std=gnu++23 -fmodule-file=somemodule=somemodule.pcm -c test.cpp -o test.o
clang++ module.o test.o -o test
./test # should run without output, exiting with 0

4. Modify the interface module code

export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    static_assert(0);  // Should fail at compile time
    *(volatile char*)nullptr = 0;  // Should fail at run time

    return i;
}

5. Compile and run as in step 3

Expected Behavior:

Changes to template function bodies should trigger recompilation of dependent code, and invalid code (static_assert(0)) should fail to compile or fail at runtime (null pointer dereference).

Actual Behavior:

Changes to template function bodies are not detected during recompilation. The program builds successfully even with invalid code in template function bodies.
This is still the case after deleting the build directory and rebuilding.

Additional Notes:

• Issue affects both standalone template functions and class member template functions
• Non-template function changes are properly detected
• Reproducible with both CMake builds and direct compilation
• Affects function bodies only; changes to template parameters, function signatures or structures are detected

Platform:

• OS: Fedora 42
• Compiler: clang version 20.1.5
• C++ Standard: C++23

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: RedNicStone (RedNicStone)

Changes to template function bodies in C++ modules don't trigger recompilation of dependent code, allowing invalid code to "compile" and run.

This issue is detrimental to the module workflow and could pose some security risks. Specifically,

• Builds silently succeed instead of an expected fail
• This issue persists across full rebuilds, since module caches are located in ~/.cache/ccache (this took me a very long time to figure out)
• It makes debugging template code de-facto impossible
• Any form of static warnings, assertions or other compile time failures may pass compilation even though they should not

Steps to Reproduce:

1. Create interface module module.ixx

export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    // static_assert(0)  // Should fail at compile time
    // *(volatile char*)nullptr = 0;  // Should fail at run time
    // We will make the above statements run and compile later, but for now we need to make it compile successfully once

    return i;
}

2. Create source file test.cpp

import somemodule;

int main() {
    return test<int>();
}

3. Build and run application

clang++ -std=gnu++23 -x c++-module -fmodule-output=somemodule.pcm -c module.ixx -o module.o
clang++ -std=gnu++23 -fmodule-file=somemodule=somemodule.pcm -c test.cpp -o test.o
clang++ module.o test.o -o test
./test # should run without output, exiting with 0

4. Modify the interface module code

export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    static_assert(0);  // Should fail at compile time
    *(volatile char*)nullptr = 0;  // Should fail at run time

    return i;
}

5. Compile and run as in step 3

Expected Behavior:

Changes to template function bodies should trigger recompilation of dependent code, and invalid code (static_assert(0)) should fail to compile or fail at runtime (null pointer dereference).

Actual Behavior:

Changes to template function bodies are not detected during recompilation. The program builds successfully even with invalid code in template function bodies.
This is still the case after deleting the build directory and rebuilding.

Additional Notes:

• Issue affects both standalone template functions and class member template functions
• Non-template function changes are properly detected
• Reproducible with both CMake builds and direct compilation
• Affects function bodies only; changes to template parameters, function signatures or structures are detected

Platform:

• OS: Fedora 42
• Compiler: clang version 20.1.5
• C++ Standard: C++23

[shafik]

CC @ChuanqiXu9 @mpark

[ChuanqiXu9]

Dependencies are controlled by build systems.

My question is, after you did step 4, whether or not the output BMI changed? If yes, then the behavior is correct. If not, I think we have a bug.

[RedNicStone]

Dependencies are controlled by build systems.

My question is, after you did step 4, whether or not the output BMI changed? If yes, then the behavior is correct. If not, I think we have a bug.

This issue is present without any build system in use, so it must be related to the compiler.
I tested the issue on two other systems, both on fedora and one with the same compiler version and one with an older compiler version (19.1.7). Only one of the systems (the one with the older compiler strangely enough) was able to replicate the issue.

The fact that both the system where I first experienced the issue and the system where I was able to replicate it have been used to compile c++ module code previously might indicate it could be related to some configuration.

In the example there is only a PCM module file but no BMI output (since --precompile is not used here). The PCM file is modified by the compiler, as are both object files. Here is me testing that in a shell:

nic@carbon:~/test$ ls
module.ixx  test.cpp
nic@carbon:~/test$ cat module.ixx 
export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    //# static_assert(0);  // Should fail at compile time
    //# *(volatile char*)nullptr = 0;  // Should fail at run time
    // We will make the above statements run and compile later, but for now we need to make it compile successfully once

    return i;
}
nic@carbon:~/test$ cat test.cpp 
import somemodule;

int main() {
    return test<int>();
}
nic@carbon:~/test$ clang++ -std=gnu++23 -x c++-module -fmodule-output=somemodule.pcm -c module.ixx -o module.o
clang++ -std=gnu++23 -fmodule-file=somemodule=somemodule.pcm -c test.cpp -o test.o
clang++ module.o test.o -o test
nic@carbon:~/test$ ./test; echo $?
0
nic@carbon:~/test$ ls --full-time
total 56
-rw-r--r--. 1 nic nic   411 2025-06-04 15:39:35.997729567 +0200 module.ixx
-rw-r--r--. 1 nic nic  1424 2025-06-04 15:41:51.748057801 +0200 module.o
-rw-r--r--. 1 nic nic 18316 2025-06-04 15:41:51.723426356 +0200 somemodule.pcm
-rwxr-xr-x. 1 nic nic 16688 2025-06-04 15:41:51.858409907 +0200 test
-rw-r--r--. 1 nic nic    59 2025-06-04 15:39:43.025825008 +0200 test.cpp
-rw-r--r--. 1 nic nic  2128 2025-06-04 15:41:51.758057900 +0200 test.o
nic@carbon:~/test$ sed -i 's/\/\/# //g' module.ixx
nic@carbon:~/test$ cat module.ixx 
export module somemodule;

volatile int i = 0;  // To ensure test is not optimized out, probably not needed
export template<typename T>
int test() {
    static_assert(0);  // Should fail at compile time
    *(volatile char*)nullptr = 0;  // Should fail at run time
    // We will make the above statements run and compile later, but for now we need to make it compile successfully once

    return i;
}
nic@carbon:~/test$ clang++ -std=gnu++23 -x c++-module -fmodule-output=somemodule.pcm -c module.ixx -o module.o
clang++ -std=gnu++23 -fmodule-file=somemodule=somemodule.pcm -c test.cpp -o test.o
clang++ module.o test.o -o test
nic@carbon:~/test$ ./test; echo $?
0
nic@carbon:~/test$ ls --full-time
total 56
-rw-r--r--. 1 nic nic   403 2025-06-04 15:42:20.777922086 +0200 module.ixx
-rw-r--r--. 1 nic nic  1424 2025-06-04 15:42:30.562441570 +0200 module.o
-rw-r--r--. 1 nic nic 18452 2025-06-04 15:42:30.539687002 +0200 somemodule.pcm
-rwxr-xr-x. 1 nic nic 16688 2025-06-04 15:42:30.733861721 +0200 test
-rw-r--r--. 1 nic nic    59 2025-06-04 15:39:43.025825008 +0200 test.cpp
-rw-r--r--. 1 nic nic  2128 2025-06-04 15:42:30.572441669 +0200 test.o