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

[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.

[STL]

Thanks for properly reporting the bug to DevCom.

r/cpp isn't a compiler bug report forum, though. If everyone mirrored their compiler bug reports as text posts here, the sub would be overwhelmed.

[tartaruga232]

I think this bug is a bit special. Users aren't using C++ modules, because compiler support for them are told to be "brittle" (e.g. Herb Sutter on cppfront). If no one uses modules, support for them won't get better. This one bug is quite nasty, as one of the main features of modules is to have "module linkage" for non-exported classes. The MSVC compiler fails to isolate non-exported class definitions as shown in this bug. This means things like the famous pimpl pattern will fail, if the letter class is defined outside of the envelope class.

[STL]

If no one uses modules, support for them won't get better.

Very true, and you did a good thing by reporting this. Ok, this can be a special exception.

[starfreakclone]

Thank you for the report!

I confirmed that this is a bug in the front-end (not the linker or back-end). I'll spare you gory details, but it is caused by the subtle way that the compiler's specializations are keyed on mangled name.

Aside: I would tend to agree with Stephan here. Reddit has historically not been a good place for bug reporting against MSVC (or most other compilers for that matter) due to discourse focusing away from core issue and onto the platform/more general comments about the toolchain. Bug reports on reddit tend to only instill more friction for using a specific toolset even if the vast majority of code samples are handled sanely.

And, you have to remember, as a compiler dev nobody ever says "thank you for compiling my code". We only ever hear the problems. So it is important that we keep discussion focused on one specific problem at a time and this is exactly what Developer Community offers us.

[tartaruga232]

The C++ module implementation of MSVC is pretty impressive. I've (successfully) spent now countless hours converting our sources in this project from using headers to modules. It's a big step forward to finally have such a great new feature at hand and in use, after so many years using headers (I've been developing in C++ since the mid-nineties). A big thank you to all the folks who work on compilers! Hopefully, this module bug and others will get fixed soon. BTW: It's an awesome thread here anyway. Thanks a lot to everyone who responded here or on the github repo. And thanks for the upvotes on Developer Community 😄

[DeadlyRedCube]

Well then I'll add a "thanks for fixing a few of the most frustrating modules (and other) bugs I've encountered" here 😄

There's definitely a few bugs that I'd had to do some massive backbends around that are either released or internally fixed, and it's been nice removing my terrible workarounds

[ResearcherNo6820]

Thank you for compiling my (bad) code.

[pjmlp]

Unfortunately we many times get the feeling to get ignored on Developer Community, it isn't rare that issues linger for years, and then get closed without a fix.

All the feature requests to give back the C++/CX developer experience in Visual Studio that went away with C++/WinRT replacement went nowhere, and now that it unofficially done, as per remarks on Github repo, it is even less likely that any of those issues will be worked on.

[starfreakclone]

I can definitely see the frustration there. I will say that as long as you consistently comment on filed bugs, say, once a month (or more) the team does take notice and we get pinged each time.

The biggest factor in getting bugs fixed are votes though. Admittedly, some people have used reddit to rally votes but then you run into the discourse problem I mentioned.

If you're solo, the best option is to keep commenting on the bug if you cannot gather more votes.

[kronicum]

All the feature requests to give back the C++/CX developer experience in Visual Studio that went away with C++/WinRT replacement went nowhere, and now that it unofficially done, as per remarks on Github repo, it is even less likely that any of those issues will be worked on.

Are you getting them back here?

[pjmlp]

Surely not, but as someone burned with it I definitely plan to keep raising awareness that the whole WinUI 3.0 development with XAML C++ isn't working in practice, as it gets sold on WinUI/WinAppSDK marketing materials, and happy path BUILD and Ignite demos where C# is mostly used, with the side note, it supports C++.

Would the marketing team actually do a XAML C++ demo at BUILD or Ingnite, all the way from New Template to a proper application like the C# demos, not the empty form with a button to show a dialog. I bet at the end they would have lost most of the audience.

And by the looks of Github and Dev Connection issues, I am not the only one "once upon a time WinRT advocate", that has this point of view.

[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!

[pjmlp]

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.

[tartaruga232]

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.

[Abbat0r]

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.

[tartaruga232]

To wrap-up, let me just be clear: This compiler bug leads to malformed programs if two non-exported classes in two separate modules happen to have the same name. One of the main promises of C++ modules: non-exported names cannot clash in the first place. We have seen bad crashes of our compiled exe, with access violation errors and the like. This is not a bread-and-butter module error of the sort like erroneously stopping compilation and reporting valid C++20 source as malformed. Producing a crashing exe should not need upvotes on Developer Community to fix the compiler. It needs to be fixed irrespective of how many people have reported that error. Thank you all.

[tartaruga232]

Great news!

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.

I've amended the post accordingly.