[C++20][Modules] error: 'std::align_val_t' has different definitions in different modules

[Ivan171]

I could not create a minimal reproducer, but I've attached the preprocessed files, which I think is enough to reproduce the issue.

Environment

Windows 10
Clang 18.0.0git (https://github.com/llvm/llvm-project 85c3953)
MSVC 2022 (17.8.1)

Reproducer

// mod2.cpp

module;

#include <utility>

export module mod2;

// mod1.cpp

module;

#include <memory>

export module mod1;

import mod2;

$ clang++.exe -std=c++20 -fno-delayed-template-parsing -fno-ms-compatibility -x c++-module mod2.cpp --precompile
$ clang++.exe -std=c++20 -fno-delayed-template-parsing -fno-ms-compatibility -x c++-module mod1.cpp -fprebuilt-module-path=.
In file included from mod1.cpp:3:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\memory:10:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\exception:8:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\yvals.h:20:
In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\crtdbg.h:13:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new_debug.h:10:
[repro.zip](https://github.com/llvm/llvm-project/files/13799238/repro.zip)
[repro.zip](https://github.com/llvm/llvm-project/files/13799246/repro.zip)

C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new.h:27:16: error: 'std::align_val_t'
      has different definitions in different modules; defined here first difference is enum with specified type 'size_t'
      (aka 'unsigned long long')
   27 |     enum class align_val_t : size_t {};
      |     ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new.h:27:16: note: but in
      'mod2.<global>' found enum with specified type 'size_t' (aka 'unsigned long long')
   27 |     enum class align_val_t : size_t {};
      |     ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

[Ivan171]

Preprocessed files

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Ivan171 (Ivan171)

I could not create a minimal reproducer, but I've attached the preprocessed files, which I think is enough to reproduce the issue.

Environment

Windows 10
Clang 18.0.0git (https://github.com/llvm/llvm-project 85c3953)
MSVC 2022 (17.8.1)

Reproducer

// mod2.cpp

module;

#include <utility>

export module mod2;

// mod1.cpp

module;

#include <memory>

export module mod1;

import mod2;

$ clang++.exe -std=c++20 -fno-delayed-template-parsing -fno-ms-compatibility -x c++-module mod2.cpp --precompile
$ clang++.exe -std=c++20 -fno-delayed-template-parsing -fno-ms-compatibility -x c++-module mod1.cpp -fprebuilt-module-path=.
In file included from mod1.cpp:3:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\memory:10:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\exception:8:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\yvals.h:20:
In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\crtdbg.h:13:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new_debug.h:10:
[repro.zip](https://github.com/llvm/llvm-project/files/13799238/repro.zip)
[repro.zip](https://github.com/llvm/llvm-project/files/13799246/repro.zip)

C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new.h:27:16: error: 'std::align_val_t'
      has different definitions in different modules; defined here first difference is enum with specified type 'size_t'
      (aka 'unsigned long long')
   27 |     enum class align_val_t : size_t {};
      |     ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files (x86)\Microsoft Visual Studio 2022\VC\Tools\MSVC\14.38.33130\include\vcruntime_new.h:27:16: note: but in
      'mod2.<global>' found enum with specified type 'size_t' (aka 'unsigned long long')
   27 |     enum class align_val_t : size_t {};
      |     ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

[koplas]

Does compiling with -fms-compatibility yield the same error?

[Ivan171]

Does compiling with -fms-compatibility yield the same error?

Yes

[ChuanqiXu9]

Oh, sad. This has the same error message with #60027...

[koplas]

Here is a reduced reproducer:

// mod1.cpp
module;

extern "C" {
    typedef unsigned __int64 size_t;
}


namespace std {
    enum class align_val_t : size_t {};
}


export module mod1;

import mod2;

// mod2.cpp
module;

extern "C" {
    typedef unsigned __int64 size_t;
 }


namespace std {
            using :: size_t;
}


extern "C++" {
    namespace std {
        enum class align_val_t : size_t {};
    }
}

export module mod2;

Seems similar to the reproducer provided by @davidstone: #60027 (comment)

[ChuanqiXu9]

This is slightly more tricky than I thought.

The reduced example can be accepted by using the canonical decl for the integral type for enum decl here:

llvm-project/clang/lib/AST/ODRHash.cpp

Lines 744 to 745 in d02c793

	if (Enum->getIntegerTypeSourceInfo())
	AddQualType(Enum->getIntegerType());

However, this may introduce false-negative issues. Now the following case will be accepted:

// mod1.cpp
module;

extern "C" {
    typedef unsigned __int64 size_t;
}


namespace std {
    enum class align_val_t : size_t {};
}

export module mod1;

import mod2;
// mod2.cpp
module;

extern "C" {
    typedef unsigned __int64 size_t;
 }


namespace std {
            using :: size_t;
}


extern "C++" {
    namespace std {
        enum class align_val_t : std::size_t {};
    }
}

export module mod2;

Now the spellings of the definition of align_val_t in two different modules are different. This violates http://eel.is/c++draft/basic.def.odr#14.4:

Each such definition shall consist of the same sequence of tokens

---

Also my "fix" only works for the reported enum case, but I believe the similar problem can occur in other places.

@zygoloid Can you take a look about how should we proceed here?

[ChuanqiXu9]

Given the reported issue has a stronger impact (we've seen multiple reports about it) and the down side of the proposed solution may only be a concern, I'd like to land the proposed solution in a few days if no more comments come in.