arm32 is not supported anymore by Windows. There has not been a native arm32 OS since before Win11. The wow32 backcompat on arm64 devices to run arm32 programs was removed with Win11 24H2. Most notably, the ability to build arm32 with newer SDKs and toolsets has seemingly been removed. This is now breaking the CI build.
The easiest fix is to simply remove arm32 support.
These failures were pointed out yesterday when the CLA policy was stuck. They are not blocking but have seemingly been failing for a long time and the failure is suppressed.
The issue seems to be that some of these test projects reference an old NuGet package while also referencing the props/targets that are about to go into the new NuGet package. Double-including essentially the same files twice is what caused the build breaks in these projects.
Some projects also had build breaks that seem to be related to a very old Windows SDK minimum version. I increased the floor to 10.0.18362.0 (early 2019; almost 6 years ago) and that fixed the remaining breaks. The random packages.config that downloaded random builds of cppwinrt from 2019 or 2020 have been deleted too.
This set of changes aims to fix the build breaks and un-suppress this failure. It now builds locally on my device but I'll need an official PR build to ensure that the GitHub Actions flow is also passing.
# Why is this change being made?
The generated projection code for interfaces that the metadata declares as required for a runtimeclass assume that QueryInterface never fails. Assuming the metadata is correct in the first place, this is a valid assumption for inproc calls.
However, for cross-process calls the QI can fail even if the metadata is correct and the class really does implement all of the required interfaces. It can fail with E_ACCESSDENIED and a variety of other RPC error codes.
When this happens there is a nullptr crash in the generated consume method. This can be very painful to debug because the HRESULT is lost by the time it crashes.
# Briefly summarize what changed
This set of changes fixes the crash by detecting the QueryInterface error and throwing an exception when that occurs during one of these required casts. The try_as method was changed to capture COM error context when the QI fails. The code gen surrounding WINRT_IMPL_STUB was changed to save the result into a temporary variable and then pass it to a new check_cast_result method. check_cast_result is marked noinline so that the binary size impact of throwing exceptions is limited to a single function instead of inlining into high-volume generated code.
If the cast succeeded then nothing happens. If the cast failed, returning null, then the stored COM exception is retrieved. Assuming it is available the HRESULT is pulled out of it and it is thrown. This then propagates like any other exception. Callers are free to try and catch it or let it go uncaught and crash. Now they have the choice.
I also added a new file of test code that exercises this code path. The test_component IDL declares a runtimeclass that implements IStringable. And then the implementation fails to implement IStringable. When ToString is called on this object it hits the failure path. The cppwinrt code gen will not allow this to happen so I had to directly use winrt::implements.
# How was this change tested?
Besides the new test cases I also wrote a little console app that crashes this way. I built and ran it using the latest stable cppwinrt as well as my private new one. As expected the debugger blame is far more useful with these changes.
We have found that a very common pattern for event handlers is
to capture a weak reference into a lambda, and in the event handler,
try to upgrade the weak reference to a strong one, and if so, do some work:
```cpp
widget.Closed([weak = get_weak(), data](auto&& sender, auto&& args)
{
if (auto strongThis = weak.get())
{
strongThis->do_all_the_things(data);
}
});
```
This commit extends the existing delegate constructors to permit a
`winrt::weak_ref` + lambda (or `std::weak_ptr` + lambda), which
simplifies the above to
```cpp
widget.Closed({ get_weak(), [this, data](auto&& sender, auto&& args)
{
do_all_the_things(data);
} });
```
## Implementation notes
A lambda and pointer to member function are hard to distinguish
in a template parameter list. In theory, we could use SFINAE or
partial specialization, but a simpler solution is to distinguish
the two inside the body of the constructor, via
`std::is_member_function_pointer_v`.
The `com_ptr` and `shared_ptr` variants of the test were
unified, since I found myself editing two nearly identical tests.
Fixes#1371
Co-authored-by: Jon Wiswall <jonwis@microsoft.com>
`resume_agile` exposes the ability to save the `await_adapter`
in a variable. This was not possible without `resume_agile` because
the `await_adapter` had previously been available only via
`operator co_await`, which means that it is created only in
response to an immediate attempt to `co_await` it, so we knew
that it would be consumed before its argument (possibly a temporary)
was destructed.
`resume_agile` returns the `await_adapter`, and we expect people
to await it immediately, but it's possible that they decide to
save it in a variable and await it later. In that case, we have
to record the `Async` as a value instead of a reference. We forward
the `resume_agile` argument into the `Async` so that it moves
if given an rvalue reference, or copies if given an lvalue reference.
This ensure that the common case where somebody does
`co_await resume_agile(DoSomething())`, we do not incur any additional
AddRefs or Releases.
Now that it's possible to `co_await` the `await_adapter` twice,
we have to worry about `await_suspend` being called twice. It had
previously assumed that `suspending` was true (since that's how it
was constructed), but that is no longer valid in the `resume_agile`
case if somebody tries to await the `resume_agile` twice. So we have
to force it to `true`. (Now, the second await will fail with
"illegal delegate assignment", but our failure to set `suspending`
to `true` led to double-resumption, which is super-bad.)
* Enable faster dev cycle in Visual Studio
* Oops, remove one more run
* Fix linux build temporarily - see also #1341
---------
Co-authored-by: Jon Wiswall <jonwis@ntdev.microsoft.com>
David Machaj
Josh Soref
Dan Legg
Kenny Kerr
Raymond Chen
Jon Wiswall
Charles Milette
Ryan Shepherd
Johan Laanstra
Dustin L. Howett
Jaiganésh Kumaran
alvinhochun