Add get_iids_tearoff() hook.

[dlech]

Add a get_iids_tearoff() hook to complement the query_interface_tearoff() hook.

query_interface_tearoff() allows dynamically extending types with additional interfaces that can be accessed with the QueryInterface() method. However, these interfaces were not discoverable by the GetIids() method (and therefore not by the winrt::get_interfaces() function either).

The get_iids_tearoff() hook allows adding the GUIDs of interfaces to the array returned by GetIids().

This also fixes a bug in the implementation of the root_implements_type::is_composing branch of NonDelegatingGetIids() where *array was updated causing the local iids to be unreachable by the caller and risking the caller reading past the end of the array.

[dmachaj]

This seems odd and possibly worth understanding before proceeding. Would you be willing to check the behavior of this test case with your get_iid_tearoff logic commented out?

[dlech]

It doesn't come from get_iid_tearoff. It is likely due to this being a composable type and the get_local_iids() of the outer class also picks up the overrideable interfaces from the inner class since overrideable interfaces get special handling.

[dmachaj]

It might be nice to have one of the test cases use an inline definition instead of deferring to a class field. Something like return winrt::array_view({winrt::guid_of<winrt::IStringable>()}); just to prove that it is possible.

[dlech]

Wouldn't that result in a dangling pointer? winrt::array_view doesn't make a copy of the underlying array AFAIKT, so the returned array view would be pointing to stack allocated memory that is no longer valid from the function that just returned.

[dmachaj]

I guess that would depend on whether it is stack allocated or compiletime. I would expect an embedded array to be compiletime and therefore non-dangling because it is part of the DLL itself.

[dlech]

The best info I could find says:

The backing array has the same lifetime as any other temporary object, except that initializing an std::initializer_list object from the backing array extends the lifetime of the array exactly like binding a reference to a temporary.

And

An object of type std::initializer_list is a lightweight proxy object that provides access to an array of objects of type const T (that may be allocated in read-only memory).

So it sounds like it can't be relied upon.

Probably using winrt::array_view for a return value was a bad idea since it could lead to dangerous usage and I should pick something else. On the other hand, there is lots of passing things by raw pointers in this part of the code anyway, so maybe it isn't any worse than what is already there.

[dlech]

Updated:

• Use std::vector instead of winrt::array_view as return value to avoid memory safety pitfalls.
• Drop const& on local_count.
• Fix mixed tabs and spaces.
• Add assertions for RuntimeType test.

[kennykerr]

I would caution against doing this. GetIids in general can and does cause code bloat due to all the static data tables it produces. @DefaultRyan did a bunch of work to mitigate the cost without turning it off entirely.

I have never seen a practical use for GetIids beyond a very obscure fallback if-all-else-fails scenario in CLR debugging that is never actually used in practice. I always noop the implementation as a result. Far better to rely on metadata for "reflection" rather than run time reflection via GetIids. 😊

[dlech]

run time reflection

The use case for this is for the PyWinRT projection, hence the need for runtime reflection. Since Python is dynamic, we need a way to add interfaces at runtime, so can't rely on static data. I can probably make something work without this if it isn't really useful for anyone else, but hooking into the existing code just makes that easier.