C++/WinRT should not assume names of user-defined implementation headers

[Scottj1s]

Originally opened here: https://github.com/microsoft/WindowsAppSDK/issues/3035

The issue is that the Windows App SDK project templates chose to name implementation headers (and sources) after the Xaml file like so: Foo.xaml Foo.idl Foo.xaml.cpp Foo.xaml.h

This was to maintain consistency with the C# project templates. The problem is when C++/WinRT needs to know the header filename, such as when generating #includes for module.g.cpp, and just assumes <typename>.h. Instead, the C++/WinRT MSBuild support should collect this information from the project file and pass it explicitly to cppwinrt.exe.

[JaiganeshKumaran]

I think having .xaml before .cpp/.h was a mistake. It's just unnecessary.

[Scottj1s]

@Jaiganeshkumaran I don't disagree, but the root issue here is with C++/WinRT

[github-actions[bot]]

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Woopsalla]

For bug analysis in WindowsAppSDK it is important to be able to disable optimization, because it seems that optimization still contains bugs. This bug report is therefore not a marginal problem. It should be processed with higher priority.

[sylveon]

I've never seen any issues with the optimized C++/WinRT mode. Do you have such examples?

[Woopsalla]

Example 1: When the code is still in the early stages, I often implement event handlers that contain the same dummy code. If you set a breakpoint in one of these handlers, you often end up in the wrong handler when debugging. This regularly led me down the wrong track in the beginning. I suspect that several handlers were simply combined here for optimization.

Example 2: The callstack is often unusable, especially when debugging events handled by methods of the generated code. I filled the generated methods in what I thought was the wrong stack with unique dummy code so that they could no longer fall victim to optimization. And indeed, the callstack changed every time.

Example 3: The most critical problem, which was probably caused by the optimization, were button clicks and checkbox events, which suddenly led to events in a completely different place in the code, e.g. switching a tab in the tabview. I investigated this problem for a long time and could not find any other explanation.

However, all these examples are just guesses. To be able to say it more exactly, one would have to be able to deactivate the optimization, which is not possible at the moment.

[kennykerr]

@Woopsalla this is unrelated to the issue that @Scottj1s opened. Please open a new issue if you would like to discuss it further. It also doesn't sound like a library issue but rather a compiler optimization issue, which is not something we can address. You can reach the Visual C++ team here: https://developercommunity.visualstudio.com/home

[Woopsalla]

Sorry, I'm not in that deep to be able to decide which site it is. That's for you guys to decide in the end. Maybe you can also provide a link that explains this in an understandable way. However, I think as long as it is not possible to turn off the C++/WinRT optimization, it also cannot be ruled out that it is the cause of these problems. And the fact is that it cannot be disabled. That is the bug. And I can't understand that this report should be closed simply because of lack of activity.

[kennykerr]

This repo is for the cppwinrt library and code generator. I wish I could help but I don't have any knowledge or experience beyond that, so if you have an issue with the build system or Xaml or Visual Studio or something else you'd have to find the relevant project or team to raise an issue.

The original issue here seems to be a feature/change request and we don't have developers available to work on cppwinrt at the moment. That code is also very much tied to the way the Xaml compiler operates, so unless the Xaml team would like to work on this issue, it will eventually be closed.

[Scottj1s]

@Woopsalla I have often seen what you describe for optimized code, typically built with Release configurations. For Debug configurations, optimizations should be disabled (/Od). But I've never seen COMDAT folding of identical function bodies like this affect behavior - the data (e.g., 'this' pointers) is always unique. If you're seeing that, then as @kennykerr recommends, an issue with a repro should be opened on the Visual Studio site.

[Woopsalla]

@Scottj1s: Thanks for joining the discussion. In our debug configurations, the /Od switch is set (so optimization is disabled). Therefore, we can rule that out as a cause. I will add the bug report for the Visual Studio team to my list. Every now and then I have to earn some money ;-)

@kennykerr: According to https://learn.microsoft.com/en-us/windows/apps/develop, the Windows App SDK is the SDK recommended by Microsoft for the development of current desktop apps. And C++/WinRT is an essential foundation of this SDK after all. And now there are no Microsoft developers to push this software? Did we bet on the wrong horse?

[kennykerr]

The cppwinrt project is mature and stable - it is used very heavily throughout Microsoft. It is not going anywhere, but that doesn't mean we continue to dedicate developers to its continued advancement.

[Woopsalla]

OK, thanks for the clarification. @Scottj1s: So if there is no solution from the C++/WinRT team, then why not reopen the original bug report and find another solution. Because the bug still exists. Or do I see this wrong?

[Scottj1s]

@Woopsalla The original bug has a workaround - renaming the .h and .cpp files. A change to the project template would do that too, but isn't general - hence the issue opened here. I'll look into a proper C++/WinRT fix, and if it's too involved, I'll consider reopening the original bug. Thanks for the feedback.

[github-actions[bot]]

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.