[Modules TS] MSVC std library produces ambiguous type_info reference when including module with ms-compatibility

[llvmbot]

Bugzilla Link	39052
Version	7.0
OS	Windows NT
Reporter	LLVM Bugzilla Contributor
CC	@dwblaikie,@DougGregor,@zygoloid

Extended Description

When compiling an project on windows using the MSVC standard library I get an ambiguous reference to type_info:

I have attached an archive of the most simple repro of the issue. It also includes the ii file from save-temps.

Error Message:
In file included from main.cpp:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\iostream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\istream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\ostream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\ios:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xlocnum:10:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\streambuf:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xiosbase:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xlocale:8:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\stdexcept:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\exception:27:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\vcruntime_exception.h:10:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\eh.h:52:14: error:
reference to 'type_info' is ambiguous
type_info const& _Type,
^
note: candidate found by name lookup is 'type_info'
note: candidate found by name lookup is 'type_info'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\eh.h:52:14: error:
reference to 'type_info' is ambiguous
note: candidate found by name lookup is 'type_info'
note: candidate found by name lookup is 'type_info'

[llvmbot]

Note: The same exact code with header based declarations works fine.

[llvmbot]

I believe I have tracked down the root issue. It seems that when I initialize the Sema under MSVCCompat it is adding the "predefined C++ types" which includes 'type_info' [llvm\tools\clang\lib\Sema\Sema.cpp 250]. Then, when the precompiled module is being generated it saves these type declarations.

The issue comes when we load of the Sema a second time for the call to compile the exe with the extra module file. The Sema initialize again adds these hard coded types and when the name lookup for the 'type_name' identifier is used it cannot figure out that the two instances it is see are both from the implicit types since that info is lost when passing through the pcm.

I do not have enough knowledge of the code to determine what the correct fix is. Do we 1) remove these hard coded types 2) prevent the ASTWriter from writing these to the pcm 3) add extra checks that we only add these types if they do not exist already in a AST file or 4) find a way to resolve these duplicate declarations?

Note: I was able to build fine by removing these types from initialize.

[llvmbot]

I am able to work around he issue for now by forcing -fno-ms-compatibility. However this issue still blocks all msvc work with modules.

[zygoloid]

I do not have enough knowledge of the code to determine what the correct fix
is.

We have a set of "predefined" declarations that we use for tracking such declarations across translation units. (See PredefinedDeclIDs in include/clang/Serialization/ASTBitCodes.h.) We should be tracking this in the same way we track the other things on that list.

[TheRustifyer]

I had the exact same issue in 2022, using Clang 14.0.4, with the MSVC toolchain. If I use the -fno-ms-compatibility, I can workaround it, but I started to getting weird errors like missing '#include <functional>'; 'std' must be declared before it is used.

There's some notice about this bug?

[m4c0]

Just for referencing/linking. I found this related issue with LLVM and C++ modules: #58532

[aaronmondal]

I'm fairly certain that this is caused by a clang/module bug with #pragma once. The microsoft standard library uses the pragma before include guards. Switching the order to be include guard first and then pragma (or just removing the pragma) will likely work around this issue.

[matts1]

I've been digging into this deeper. It appears to be unrelated to pragmas. The issue appears to be here.

I've created a minimal example here to reproduce the problem.

To sum up the results:

• When you precompile the module first.pcm, it successfully references type_info and inserts into the TU for that module
• When you precompile the module second.pcm, it successfully references type_info and inserts into the TU for that module
• When you precompile the module second.pcm but add -fmodule-file=first.pcm, it finds it ambigious - there's the version from our own local scope, and the version from the module first.pcm

What really confuses me though, is that it should be creating a forward declaration, not a definition, so the ambiguity shouldn't matter.