[C++20][Modules] Clang ignores #pragma comment(lib, ...) directives

[Ivan171]

Module version:

$ cat mod.cpp
module;

#pragma comment(lib, "msvcprt.lib")

export module mod;

$ clang++.exe -std=c++20 -x c++-module mod.cpp -c -S -emit-llvm

$ cat mod.ll
; ModuleID = 'C:\Users\IVAN\AppData\Local\Temp\mod-3e93fd.pcm'
source_filename = "C:\\Users\\IVAN\\AppData\\Local\\Temp\\mod-3e93fd.pcm"
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc19.35.32216"

!llvm.linker.options = !{}
!llvm.module.flags = !{!0, !1, !2, !3}
!llvm.ident = !{!4}

!0 = !{i32 1, !"wchar_size", i32 2}
!1 = !{i32 8, !"PIC Level", i32 2}
!2 = !{i32 7, !"uwtable", i32 2}
!3 = !{i32 1, !"MaxTLSAlign", i32 65536}
!4 = !{!"clang version 17.0.0 (https://github.com/llvm/llvm-project c82803097f6a89edc49577e5bb4f7309e053efcc)"}

Non module version:

$ cat nomod.cpp
// module;

#pragma comment(lib, "msvcprt.lib")

// export module mod;

$ clang++.exe -std=c++20 nomod.cpp -c -emit-llvm -S

$ cat nomod.ll
; ModuleID = 'nomod.cpp'
source_filename = "nomod.cpp"
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc19.35.32216"

!llvm.linker.options = !{!0}
!llvm.module.flags = !{!1, !2, !3, !4}
!llvm.ident = !{!5}

!0 = !{!"/DEFAULTLIB:msvcprt.lib"}
!1 = !{i32 1, !"wchar_size", i32 2}
!2 = !{i32 8, !"PIC Level", i32 2}
!3 = !{i32 7, !"uwtable", i32 2}
!4 = !{i32 1, !"MaxTLSAlign", i32 65536}
!5 = !{!"clang version 17.0.0 (https://github.com/llvm/llvm-project c82803097f6a89edc49577e5bb4f7309e053efcc)"}

In the module version there's no /DEFAULTLIB:msvcprt.lib attribute. The MSVC STL uses #pragma comment to attach linker flags to object files, so that at linking time the right set of flags/libraries are used.

If something like <optional> is used, there's no problem, but if <iostream> (there's others as well) is used for example, we'll get a lot of unresolved symbol errors from the linker, because we're not linking the right libraries (msvcprt.lib in this case).

The directive #pragma detect_mismatch (and possibly others) is also being ignored by Clang when building modules.

[llvmbot]

@llvm/issue-subscribers-clang-modules

[dwblaikie]

Generally clang doesn't support the comment lib pragma, in modules or not - you'd need to pass the relevant linker flag to link the library.

I don't think this is a uniquely modular bug/a fairly generic clang-cl feature request.

[Ivan171]

Generally clang doesn't support the comment lib pragma, in modules or not - you'd need to pass the relevant linker flag to link the library.

I don't think this is a uniquely modular bug/a fairly generic clang-cl feature request.

Clang does support the comment pragma. I've never had to manually specify the MSVC runtime libraries to a linker.

Here is the commit that added support for it. And here is the related issue.

[dwblaikie]

Generally clang doesn't support the comment lib pragma, in modules or not - you'd need to pass the relevant linker flag to link the library.
I don't think this is a uniquely modular bug/a fairly generic clang-cl feature request.

Clang does support the comment pragma. I've never had to manually specify the MSVC runtime libraries to a linker.

Here is the commit that added support for it. And here is the related issue.

Oh, thanks for the context - I didn't realize/went looking for an existing issue.

Yeah, so maybe this is modules-specific, then. Perhaps we don't serialize the pragma properly.

[iains]

we do not do anything special for C++20 modules w.r.t pragmas, so I'd guess that this problem would also show with PCH?

[ChuanqiXu9]

Oh, this is related to eager loading. Let me try to handle this.

[Ivan171]

we do not do anything special for C++20 modules w.r.t pragmas, so I'd guess that this problem would also show with PCH?

I've done a quick test here and the pragma does work with precompiled headers.

[ChuanqiXu9]

The direct cause for the issue is that I banned the eagerly loading for declarations from named modules to speedup the process of reading modules (See #61064 for example). I thought it makes sense because the mechanism to load declarations eagerly is designed for header modules. But I didn't think about PragmaCommentDecl and PragmaDetectMismatchDecl. So here is the issue.

Note that the inconsistency to load declarations from named modules is still problematic. See #61783 for example. I reverted the previous patch since I feel it is more important to not break the user's code than compilation speed. I'll try to handle this properly before the release of 17.