MSVC internal compiler error with C++20 modules

[DatCaptainHorse]

GH Actions Build error line: https://github.com/DatCaptainHorse/ChatNotifier/actions/runs/8380416839/job/22949592674#step:5:330

I love how glaze works out of the box and was easy to add, but on Windows (with modules atleast) MSVC screams.

Can be closed if there's nothing that can be done on your side 🙏

[stephenberry]

I really want to support modules, but the compiler support is still suffering. I probably won't be able to debug MSVC module building of glaze for a while, but it is on my radar.

[SevenDayCandle]

I had been running into similar issues with the MSVC compiler as well when building a project based on C++ modules with the MSVC compiler through Visual Studio.

With the latest preview version of Visual Studio (17.10 Preview 3), which I believe is bundled with version 19.40.33721.2 of MSVC, I am able to compile my project successfully if I put includes for glaze before the module export declaration like this:

module;
#include "glaze/glaze.hpp"
export module mymodule;

However, if I use glaze functions in any template function, the compiler fails with the same internal compiler error mentioned at the start of this post, even if I am never actually passing any variables with that template type to the glaze functions. When this happens, I see another error in Visual Studio:

Error (active)	E2916	no valid std::strong_equality type found (<compare> must be included)	RProject	D:\1089C\Documents\VisualStudio\Fabricate\Dependencies\Glaze\include\glaze\tuplet\tuple.hpp	111		

[stephenberry]

Thanks a lot for the update. I might try experimenting with MSVC modules support soon. It's curious that it's complaining about the tuple, I've been intending to simplify some of that code, which would hopefully help the compiler.

[stephenberry]

From reading about current modules implementations it seems like compilers struggle with template specializations in the std namespace. Glaze only does this for its internal tuple, so I'll try to refactor the code to remove this behavior and hopefully help Glaze work with current implementations.

[kelteseth]

@stephenberry Please create a PR when module support works, so we can track it at https://arewemodulesyet.org/ https://github.com/kelteseth/arewemodulesyet :)

[stephenberry]

I just merged in #961, which removes std specializations from glaze and adds its own (for tuple_size and tuple_element).

For those who test glaze with modules, please keep adding the issues you see here so that we can try to tackle them.

[kelteseth]

Sorry to ask here @stephenberry but whats your experience with modules support in general? I'm thinking about adding Like a 3 step support level to arewemodulesyet table on the start page, because by the comments here, there can be issues even importing regular code into a modules project:

1. LibraryX can be used in a modules project
2. LibraryX itself is a modules project
3. All of LibraryX dependencies are modules
4. LibraryX uses C++23 import std;
5. All of LibraryX dependencies are using C++23 import std;

And my guess we will see only a real increase in compiler times if we are at least at step 3 or 5.

[SevenDayCandle]

Unfortunately, I still see the same compiler errors with the same test case detailed in my previous post with glaze 2.6.0

• C1001: Internal compiler error. (compiler file 'D:\a_work\1\s\src\vctools\Compiler\CxxFE\sl\p1\c\module\utilities.h', line 48)
• E2916: no valid std::strong_equality type found ( must be included)

[stephenberry]

@SevenDayCandle, thanks for the update
@kelteseth, I have not yet tried to build a C++20 modules project that includes Glaze. That will be the first step. Glaze has no other dependencies, so there won't be an issue there. And, I am greatly looking forward to import std;

Could someone point me to a bleeding edge basic CMake project that supports C++20 modules? Or, throw one together for testing Glaze? I'd be happy testing on MSVC.

[stephenberry]

I was able to get MSVC building (not with Glaze) with CMake and import std;

MSVC does not currently allow mixing import std with traditional #include for std includes.

This is currently a compile time bug in MSVC:

import std;
#include <vector>

This means that I have to use import std everywhere in Glaze if I am going to make Glaze compatible with C++20 modules in MSVC. Glaze only depends on the stl, so this is feasible. It will just require some macro guards and then adding macro exports to export the user facing API.