Reliably diagnose stack allocations in C++/WinRT

[kennykerr]

I previously introduced a runtime assertion to help diagnose and catch stack allocation bugs in C++/WinRT. Unfortunately, there are just too many cases where this does not catch stack allocations. Notably, if the local is created within a coroutine frame then it won't detect it since the coroutine frame is itself allocated on the heap. This update turns this runtime assertion into a compiler error that should catch such mistakes in all cases.

struct Sample : implements<Sample, IStringable>
{
    hstring ToString() { return L"Sample"; }
};

IAsyncOperation<hstring> Async()
{
    co_await resume_background();
    IStringable s = Sample(); // <-- Oops!
    co_return s.ToString();
}

error C2259: 'Sample': cannot instantiate abstract class 
  ... use_make_function_to_create_this_object ...

Double clicking on the error brings the developer to this helpful comment:

// Please use winrt::make<T>(args...) to avoid allocating a C++/WinRT implementation type on the stack.
virtual void use_make_function_to_create_this_object() = 0;

This does mean that private destructors aren't supported, but that's already a requirement if you want to use the final_release feature (deferred destruction) and the only reason you'd want a private destructor is to prevent someone from accidentally calling delete ptr and C++/WinRT makes that quite hard to do since you really have to go out of your way to get hold of a raw pointer in C++/WinRT. C++/WinRT then also ensures that all implementations are final, which provides the C++ optimizer the possibility to devirtualize further.

[DefaultRyan]

Port to cppx

[kennykerr]

I have a few things lined up where cppwinrt and cppx have diverged and I'm preparing a PR to bring them all in.

[Scottj1s]

Can we issue a static_assert and more friendly message instead?

[kennykerr]

Sadly I haven't found a way to express this with a static_assert.