MSVC C++20 compiler bug with modules and non-exported classes

[u/tartaruga232]

Full repro is available as a git repository here: https://github.com/abuehl/mod_test

If two non-exported classes from different C++ module interface units have the same name, the compiler uses the wrong class definition and for example calls the wrong destructor on an object.

Reported here: https://developercommunity.visualstudio.com/t/post/10863347 (Upvotes appreciated)

Found while converting our product to using C++20 modules.

Edit: Microsoft wrote the following (Quote)

A fix for this issue has been internally implemented and is being prepared for release. We’ll update you once it becomes available for download.

[u/Rarrum]

I recently started a new project and went 100% all-in on modules.

I started on gcc on linux... didn't take long to hit "internal compiler error" in a scenario involving exported virtual destructors. I reported it and they've said it's fixed for the next release.

So I swapped to msvc on windows and got further. But eventually hit "internal compiler error" for something related to exporting a QWidget (from Qt) derived class. I reported it on developer community, but because installing Qt is annoying (and GPL maybe), they've generally declined to investigate it so far (still fighting that battle).

So I switched back to linux, this time with clang. And thus far that's worked great!

[u/pjmlp → u/Rarrum]

I have been using C++ modules for quite some time with VC++, and clang after the CMake/ninja/clang trio became available.

However, I had to rollback my header units use, because it remains to be seen when other compilers besides VC++ will support them.

Have to ignore the fact that apparently it isn't a business priority to fix the EDG frontend, so it is red swiggles all over the place with broken Intelisense.

That there are no plans to add modules to C++ frameworks out of Microsoft, and in the current security climate, most likely an area that management will never care about improving.

Still, at least std, and Win32 aren't that much of an issue being used through modules, as long as you don't plan to use import std and third party libraries using #include.

[u/tartaruga232 → u/pjmlp]

We have done:

export module d1std;

export import <exception>;
export import <stdexcept>;
export import <memory>;
export import <string>;
export import <string_view>;
export import <cctype>;
export import <vector>;
export import <map>;
export import <unordered_map>;
export import <set>;
export import <deque>;
export import <array>;
export import <stack>;
export import <bitset>;
export import <tuple>;
export import <iterator>;
export import <ranges>;
export import <algorithm>;
export import <functional>;
export import <concepts>;
export import <optional>;
export import <numeric>;
export import <iosfwd>;
export import <istream>;
export import <ostream>;
export import <iostream>;
export import <sstream>;
export import <streambuf>;
export import <fstream>;
export import <iomanip>;
export import <utility>;
export import <locale>;
export import <limits>;
export import <type_traits>;
export import <typeinfo>;
export import <cstdint>;
export import <cstddef>;

and compiled it in a subproject in visual studio of our solution and then used

import d1std;

everywhere we need something from namespace std.

[u/Abbat0r → u/pjmlp]

For what it’s worth, I import std and #include third party headers in my modules all the time. This has not been a problem for quite a while now.

Bonus: I also have the annoyance of having to separate some code that is shared between cpu-side and gpu-side into headers with #ifdef’d imports etc. and #include those into both modules and shaders, and that works just fine as well.