Bug: Spurious IntelliSense errors with C++20 Modules

Version

3.0.260715.1

Summary

A simple project that uses C++/WinRT with the new C++20 Modules feature can build successfully with MSVC 14.52 Preview in Visual Studio Insiders, but has IntelliSense errors in the IDE that get in the way of return type deduction and similar. For instance, the example code causes this IntelliSense error:

function "winrt::Windows::Foundation::IUnknown::operator new(size_t)" (declared at line 2117 of module "winrt_base" ("D:\...\winrtmodcom\x64\Debug\Generated Files\winrt\base.h")) cannot be referenced -- it is a deleted function

More likely than not, this is simply an IDE and IntelliSense bug and I've reported it as such in DevCom-11123562. Anyone who cares about this scenario is welcome to upvote it. Having said that, if there's any workaround that can be implemented on the cppwinrt side to mitigate these IntelliSense failures, it would be a welcome improvement to the user experience.

Reproducible example

import std;
import winrt_base;
import winrt.Windows.Foundation;

winrt::Windows::Foundation::IAsyncOperation<winrt::hstring> GetStringAsync()
{
    co_return L"Hello, World!";
}

winrt::Windows::Foundation::IAsyncOperation<winrt::hstring> foo()
{
    auto str = co_await GetStringAsync(); // IntelliSense labels this <error type> instead of figuring out it is a winrt::hstring.
    co_return str;
}

Expected behavior

IntelliSense should be fully functional with cppwinrt C++20 Modules in scenarios that work correctly with header files.

Actual behavior

IntelliSense reports spurious E1776 errors and fails to deduce return types

Additional comments

No response

Inizia con l’esempio riproducibile di C++20 Modules usando import std, import winrt_base e import winrt.Windows.Foundation in Visual Studio Insiders con MSVC 14.52 Preview. Confronta il comportamento di IntelliSense con quello del progetto equivalente basato su header ed esamina il winrt\base.h generato menzionato nell’errore. Il lavoro è completato quando viene identificato un workaround lato cppwinrt per i falsi positivi E1776 oppure viene confermato che il problema deve essere risolto in DevCom-11123562.