C++ modules example fails on LLVM 15.0.7 for 64-bit Windows - delayed template parsing is not supported/broken with C++ modules #61068
Comments
EugeneZelenko
added
clang:modules
|
@llvm/issue-subscribers-clang-modules |
|
Could you please try 16 or |
|
@EugeneZelenko, I will try. Thank you. |
|
@EugeneZelenko, I am not succeeding at entering this example into godbolt because it has to import the BMI from module M, but there is no way to save a BMI in godbolt AFAIK. I could paste a screenshot of "fatal error: module M not found" but that would not be useful. There are no LLVM releases past 15.0.7 for Windows. If I cloned the trunk of LLVM from GIT I would have to build it on MSVC, and are the instructions for that even public? I did upload my complete source (same as the example in the docs plus the nine Windows command lines in a powershell-script for compiling/linking the example) so anyone with a Windows PC with LLVM installed could confirm it. |
|
Hmm I'm pretty sure that this should work with Clang 16 or upstream. It may be an unsatisfactory workaround, but with Docker and WSL things tend to be easier to get running. E.g. the a Gentoo and Arch baseimages have more recent versions available in their package managers. |
|
@aaronmondal In fact it does work on my Clang v15.0.7 on 64-bit Windows, as long as I change the backend to a gcc cross-compiler, using Clang to produce MIPS instructions and pass that on to my runs-on-Windows/targets-MIPS version of gcc. My workflow with LLVM is ultimately for the cross-compiler but I am also hoping to test my code on Windows. So, in short, I need Clang to work on both targets but currently it is working on only one of them. As to the version of Clang, the example is from the Clang 15.0.0 docs (see the hyperlink in my first post). It is presented there as the Hello World of modules. Plus, the Clang 15 release notes say "Implemented PR1103R3: Merging Modules," which, if I understand, is the paper that merges modules into the C++20 standard, and includes module partitions. The Clang Status page says the same thing. I am sure Clang would not announce that in the 15 release notes and have 15 on the status page and include a sample project in the 15 docs if it were so seriously broken in 15. TL;DR: Works on other configurations of Clang 15, problem is just in the MSVC backend. |
|
Update: I installed llvm 16.0.0 today from the official release. Example still does not work. However, error message is different: (Interesting note: I don't know if you can see this in github, but on my terminal in the fixed-width font, the first line of tildes extends from the v in void to the t in noexcept, not including the opening brace of the function body. The second line of tildes includes the opening brace.) |
Things usually works better under Windows if you use Mingw and links against stdlibc++. I typically preferred to link against libc++, but in Windows isn't working with flags like -fimplict-modules, -fimplicit-module-maps |
|
|
Upgraded to LLVM 16.0.5 today. Confirming that this issue still exists. |
|
The issue still exists in LLVM 17.0.1, and the error message has actually gotten a little more verbose since when I last tried it, in 16.0.5... |
|
The issues reported here since the first post look like a duplicate of #60027 |
|
@davidstone I agree with you. I would be fine with combining the issues. |
|
By request... my preprocessor output! All 7 megabytes of it. |
|
Does the issue still occurs if you write your // impl_part.cppm
module;
#include <iostream>
#include <string>
module M:impl_part;
import :interface_part;
// Comment out the string assignment
// std::string W = "World.";
void World() {
std::cout << "World." << std::endl;
} |
|
@koplas Yes, if I don't instantiate the |
|
It seems like functions that are not referenced or used are stripped of their body. For example, the method And As a workaround, you can add a dummy |
|
You are on to something, but unfortunately I am doing something wrong with that workaround, it isn't working around for me... |
|
@csimon-bambecksystems Can you try the original reproducer with For more info:
Note this also fails on Linux with |
|
@koplas omg... that worked!
So that was it, the example doesn't work with delayed template parsing (which means, I guess, clang C++ standard modules does not work yet with delayed templated parsing?). Which means it didn't work for naive Windows users who have delayed template parsing turned on by default. EDIT: If |
|
@ChuanqiXu9 Maybe add a note to the docs that delayed template parsing is not supported/broken with C++ modules? |
Nice catch! Will done! |
ChuanqiXu9
changed the title
…s not working with modules Catched in #61068. Add this to the document to avoid further misunderstandings.
|
And it is pretty helpful to provide a minimal reproducer to solve the underlying issue. |
|
@csimon-bambecksystems Can you share the output of |
|
@koplas Output of: |
|
Here is a reproducer that also runs on Linux: delayed-template-parsing.zip |
Oh, it is good enough that it doesn't contain any third-party headers (including STLs). One suggestion may be to put such small reproducer directly instead of putting a .zip. I admit I got scared when seeing the .zip. |
|
I sent #69431 |
… default on windows after c++20 There are already 3 issues about the broken state of -fdelayed-template-parsing and C++20 modules: - llvm#61068 - llvm#64810 - llvm#65027 The problem is more complex than I thought. I am not sure how to fix it properly now. Given the complexities and -fdelayed-template-parsing is actually an extension to support old MS codes, I think it may make sense to not enable the -fdelayed-template-parsing option by default with C++20 modules to give more user friendly experience. Users who still want -fdelayed-template-parsing can specify it explicitly. Given the discussion in llvm#69551, we decide to not enable -fdelayed-template-parsing by default on windows after c++20
… default on windows with C++20 (#69431) There are already 3 issues about the broken state of -fdelayed-template-parsing and C++20 modules: - #61068 - #64810 - #65027 The problem is more complex than I thought. I am not sure how to fix it properly now. Given the complexities and -fdelayed-template-parsing is actually an extension to support old MS codes, I think it may make sense to not enable the -fdelayed-template-parsing option by default with C++20 modules to give more user friendly experience. Users who still want -fdelayed-template-parsing can specify it explicitly. Also according to https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170, MSVC actually defaults to -fno-delayed-template-parsing (/Zc:twoPhase- with MSVC CLI) if using C++20. So we match the behavior with MSVC here to not enable -fdelayed-template-parsing by default after C++20.
|
Originally, I thought #69431 is simply a workaround. But according to the later discussions, I found it may be a proper solution since now we treat |
The documentation here provides the following Hello-World style example:
Precompiling the module
Compiling the user
Compiling the module and linking it together
I tried this exact example on LLVM 15.0.7 for 64-bit Windows. The files are included. The standard library and linker/backend in my environment is MSVC 17.5.1. I have changed the command lines slightly for Windows. The result is a strange failure at
Impl.cpp:Note, I can compile, link and execute a regular "Hello World" (without C++20 modules) in my LLVM environment just fine, it is only behaving this way when it imports modules and includes system headers in global module fragments of those imported modules.
test2.zip
The text was updated successfully, but these errors were encountered: