[C++20][Modules] Can't use same legacy header in different modules

[SasisaDev]

module;

#include <concepts>

export module Services:Service;

module;

#include <iostream>

export module Log;

Results in this error

D:\VisualStudio\VC\Tools\MSVC\14.34.31933\include\vcruntime_new.h:27:16: error: 'std::align_val_t' has different definitions in different modules; definition in module 'Log.<global>' first difference is enum with specified type 'size_t' (aka 'unsigned long long')
    enum class align_val_t : size_t {};
    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
D:\VisualStudio\VC\Tools\MSVC\14.34.31933\include\vcruntime_new.h:27:16: note: but in 'Services:Service.<global>' found enum with specified type 'size_t' (aka 'unsigned long long')
    enum class align_val_t : size_t {};
    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Both headers at one point include vcruntime_new.h header.
No using namespace std; used.
Obviously, definitions are not different, they're just not removed by clang when building tree.
I used these commands to build

[PCM] clang++ -std=c++20 -fmodules  -g -O0  -Wall  -DPLATFORM_WINDOWS 
-fprebuilt-module-path=D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules  
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Engine.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Services.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Engine.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Services.lib 
--precompile D:\UnixProjects\General\Bismuth\BismuthEngine\Source\Engine\Application\Application.cppm
-o D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Application.pcm 

[LIB] clang++ -std=c++20 -fmodules  -g -O0  -Wall  -DPLATFORM_WINDOWS 
-fprebuilt-module-path=D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules  
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Engine.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Services.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Engine.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Services.lib 
-c  D:\UnixProjects\General\Bismuth\BismuthEngine\Source\Engine\Application\Application.cppm 
-o D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Application_temp\Application_interface.obj

[LINKER] lld-link  /lib D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Engine.lib 
D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Services.lib     
/out:D:\UnixProjects\General\Bismuth\BismuthEngine\Intermediate\Modules\Application.lib

[llvmbot]

@llvm/issue-subscribers-clang-modules

[ChuanqiXu9]

hi, the reproducer looks odd to me since that we don't likely meet the problems if we don't import Log to Services:Service or import them to the same TU. Could you try to provide the full reproducer and the corresponding comamnds line.

[davidstone]

I have reproduced this issue with libstdc++, so I suspect it's the same problem here. I'll describe my libstdc++ issue:

bits/align.h includes stdint.h, which provides the type ::uintptr_t. If cstdint is included before that, then there is also the type ::std::uintptr_t. The function is defined in namespace std, but references uintptr_t (no qualifications or scope resolution). This means that some translation units refer to ::std::uintptr_t and some refer to ::uintptr_t. Even though ::std::uintptr_t is defined as namespace std { using ::uintptr_t; }, this is treated as a violation of the ODR. I don't know if that is an actual violation. Here is the fully reduced test case from libstdc++:

module;

using uintptr_t = unsigned long;

namespace std {

using ::uintptr_t;

void align() {
  uintptr_t x;
}

} // namespace std

export module a;

module;

using uintptr_t = unsigned long;

namespace std {

void align() {
  uintptr_t x;
}

} // namespace std

export module b;

export module c;

import a;
import b;

Compile with

clang++ -std=c++20 -x c++-module a.cpp --precompile -o a.pcm
clang++ -std=c++20 -x c++-module b.cpp --precompile -o b.pcm
clang++ -std=c++20 -x c++-module c.cpp --precompile -o c.pcm -fmodule-file=a.pcm -fmodule-file=b.pcm

Outputs

In file included from c.cpp:1:
b.cpp:7:6: error: 'std::align' has different definitions in different modules; definition in module 'b.<global>' first difference is function body
void align() {
~~~~~^~~~~~~~~
a.cpp:9:6: note: but in 'a.<global>' found a different body
void align() {
~~~~~^~~~~~~~~
1 error generated.

I'm assuming Visual Studio's headers have a similar problem, so to workaround you can include the cwhatever header first, if you can figure out which symbol is being referenced. Then you'll always get the ::std:: version.

[ChuanqiXu9]

Thanks for the minimal reproducer! It helps a lot. I think this is not a real ODR violation. Since http://eel.is/c++draft/basic.def.odr#14.5 said the names inside the functions should refer to the same entity after the lookup. And ::std::uintptr_t and ::uintptr_t should have the same type. So they should be the same entity. So this is not a ODR violation and this should be a compiler bug.

[masx200]

[ 37%]: compiling.module.test leetcode_treenode_cpp.freeTreeNode
"C:\\Program Files\\LLVM\\bin\\clang" -c -x c++-module -fmodule-output=build\.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.freeTreeNode.pcm -fmodule-file=leetcode_treenode_cpp.TreeNode=build\.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.TreeNode.pcm -Qunused-arguments -m64 -std=c++20 -D__TEST__ -fexceptions -fcxx-exceptions -isystem C:\Users\Administrator\Documents\vcpkg-master\installed\x64-windows-static\include -fmodules-cache-path=build\.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache -fmodule-file=leetcode_treenode_cpp.TreeNode=build\.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.TreeNode.pcm -o build\.objs\leetcode-treenode-cpp\windows\x64\test\freeTreeNode.ixx.obj freeTreeNode.ixx
error: @programdir\modules\private\async\runjobs.lua:256: @programdir\rules\c++\modules\modules_support\clang.lua:270: @programdir\modules\core\tools\gcc.lua:721: In file included from traversalTreeNode.ixx:2:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\vector:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\xmemory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\new:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\exception:12:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2186:19: error: 'std::hash' has different definitions in different modules; first difference is defined here found method '_Do_hash' with no body
    static size_t _Do_hash(const _Kty& _Keyval) noexcept {
    ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2186:19: note: but in 'leetcode_treenode_cpp.TreeNode.<global>' found method '_Do_hash' with body
    static size_t _Do_hash(const _Kty& _Keyval) noexcept {
    ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from traversalTreeNode.ixx:2:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\vector:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\xmemory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\new:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\exception:12:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2167:23: error: 'std::_Conditionally_enabled_hash' has different definitions in different modules; first difference is defined here found method 'operator()' with no body
    _NODISCARD size_t operator()(const _Kty& _Keyval) const
               ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2167:23: note: but in 'leetcode_treenode_cpp.TreeNode.<global>' found method 'operator()' with body
    _NODISCARD size_t operator()(const _Kty& _Keyval) const
               ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

[ChuanqiXu9]

[ 37%]: compiling.module.test leetcode_treenode_cpp.freeTreeNode
"C:\Program Files\LLVM\bin\clang" -c -x c++-module -fmodule-output=build.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.freeTreeNode.pcm -fmodule-file=leetcode_treenode_cpp.TreeNode=build.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.TreeNode.pcm -Qunused-arguments -m64 -std=c++20 -D__TEST__ -fexceptions -fcxx-exceptions -isystem C:\Users\Administrator\Documents\vcpkg-master\installed\x64-windows-static\include -fmodules-cache-path=build.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache -fmodule-file=leetcode_treenode_cpp.TreeNode=build.gens\leetcode-treenode-cpp\windows\x64\test\rules\modules\cache\ec4a91a6\leetcode_treenode_cpp.TreeNode.pcm -o build.objs\leetcode-treenode-cpp\windows\x64\test\freeTreeNode.ixx.obj freeTreeNode.ixx
error: @programdir\modules\private\async\runjobs.lua:256: @programdir\rules\c++\modules\modules_support\clang.lua:270: @programdir\modules\core\tools\gcc.lua:721: In file included from traversalTreeNode.ixx:2:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\vector:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\xmemory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\new:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\exception:12:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2186:19: error: 'std::hash' has different definitions in different modules; first difference is defined here found method '_Do_hash' with no body
static size_t _Do_hash(const _Kty& _Keyval) noexcept {
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2186:19: note: but in 'leetcode_treenode_cpp.TreeNode.' found method '_Do_hash' with body
static size_t _Do_hash(const _Kty& _Keyval) noexcept {
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from traversalTreeNode.ixx:2:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\vector:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\xmemory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\new:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\exception:12:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2167:23: error: 'std::_Conditionally_enabled_hash' has different definitions in different modules; first difference is defined here found method 'operator()' with no body
_NODISCARD size_t operator()(const _Kty& _Keyval) const
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\type_traits:2167:23: note: but in 'leetcode_treenode_cpp.TreeNode.' found method 'operator()' with body
_NODISCARD size_t operator()(const _Kty& _Keyval) const
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

This should fall in the category of #61807.

[csimon-bambecksystems]

@masx200 @ChuanqiXu9 I have one more reproducer for you... unfortunately it's the modules "Hello World" example direct from LLVM's documentation (https://clang.llvm.org/docs/StandardCPlusPlusModules.html).

// M.cppm
export module M;
export import :interface_part;
import :impl_part;
export void Hello();

// interface_part.cppm
export module M:interface_part;
export void World();

// impl_part.cppm
module;
#include <iostream>
#include <string>
module M:impl_part;
import :interface_part;

std::string W = "World.";
void World() {
  std::cout << W << std::endl;
}

// Impl.cpp
module;
#include <iostream>
module M;
void Hello() {
  std::cout << "Hello ";
}

// User.cpp
import M;
int main() {
  Hello();
  World();
  return 0;
}

Now I build the example on my Windows PC with the following commands:

clang++ -std=c++20 interface_part.cppm --precompile -o M-interface_part.pcm
clang++ -std=c++20 impl_part.cppm --precompile -fprebuilt-module-path='.' -o M-impl_part.pcm
clang++ -std=c++20 M.cppm --precompile -fprebuilt-module-path='.' -o M.pcm
clang++ -std=c++20 Impl.cpp -fprebuilt-module-path='.' -fmodule-file=M='M.pcm' -c -o Impl.obj # Fails

The compilation of Impl.cpp fails with this error:

C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\include\xstring:2993:10: error:
      'std::basic_string' has different definitions in different modules; first difference is defined here found method
      '_Memcpy_val_from' with no body
 2993 |     void _Memcpy_val_from(const basic_string& _Right) noexcept {
      |     ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\include\xstring:2993:10: note:
      but in 'M:impl_part.<global>' found method '_Memcpy_val_from' with body
 2993 |     void _Memcpy_val_from(const basic_string& _Right) noexcept {
      |     ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2994 |         _STL_INTERNAL_CHECK(_Can_memcpy_val);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2995 |         const auto _My_data_mem =
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~
 2996 |             reinterpret_cast<unsigned char*>(_STD addressof(_Mypair._Myval2)) + _Memcpy_val_offset;
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2997 |         const auto _Right_data_mem =
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2998 |             reinterpret_cast<const unsigned char*>(_STD addressof(_Right._Mypair._Myval2)) + _Memcpy_val_offset;
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2999 |         _CSTD memcpy(_My_data_mem, _Right_data_mem, _Memcpy_val_size);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 3000 |     }
      |     ~

My clang is v17.0.1.

[ChuanqiXu9]

The root problems of such issues are the compiler failed to recognize the sameness of declarations in different translation unit. And this is not a single problem but a catagory of problems. And we probably can only fix them one by one unless we'd like to invent a new BMI format. That said, your issue may still exist after the reproducer of the issue itself got fixed.

@csimon-bambecksystems So I believe your report worths a standalone issue. Also since I don't have a windows developing environment, it would be much more helpful if you can reduce it so that it doesn't depends on MSSTL. We can achieve this by preprocess the source files and delete things from it. It is pretty touch and time consuming though..