Allow visualization of properties on generic types #1472
Conversation
| {"Object", ElementType::Object} | ||
| }; | ||
| std::string_view partName = *it; | ||
| auto basic_type_pos = std::find_if(std::begin(elementNames), std::end(elementNames), [&partName](auto&& elem) { return elem.first == partName; }); |
There was a problem hiding this comment.
Does this need to be case insensitive?
There was a problem hiding this comment.
That's a good question, and I had to really think about this answer. From everything I've learned about WinRT over the years, the exact casing of the string returned by GetRuntimeClassName is not prescribed by the type system, just that "In particular, IInspectable.GetRuntimeClassName enables an object's client to retrieve a WinRT typename that can be resolved in metadata to enable language projection." (source https://learn.microsoft.com/en-us/uwp/winrt-cref/winrt-type-system)
That same WinRT type system doc linked above also calls out the names of these fundamental types, so these exact strings are standard, with the exception of Object. What isn't strictly specified in the standard is that an implementation's internal type for a generic must return a particular string from GetRuntimeClassName.
With a concrete type that implements generic interfaces, like Windows.Foundation.Collections.ValueSet, it only needs to return that string. After looking up that string in the winmd, the relationship of the runtime class to the various generic interfaces it implements is all captured in the ECMA metadata.
But with these implementation-supplied objects, the class name is more of a convention, rather than a dictate of the type system, as far as I can tell. But what I do know is that I checked 3 of the big implementations that actually generate matching pinterface GUIDs and runtime class names, and they all use these same names. So, I think we're good here.
There was a problem hiding this comment.
I did just notice that I need to validate Char16 and Guid. I'm also going to ping the CsWinRT owners to verify they also return consistent strings for these cases.
We can now visualize properties on generic types. For example:
IReference<T>.ValueIVector<T>.SizeIKeyValuePair<T>.KeyandIKeyValuePair<T>.ValueThis does the heavy lifting of parsing the generic type strings received from the debugger, synthesizing type signatures for generics, calculating the pinterface UUID, and retrieving the property.
Note that this change only attacks true properties. For collections, (e.g. Vector, Map), only
Sizeis a property. Obtaining the contents requires non-property method calls. Fortunately, I have an idea for that which I'll add in a separate PR.Fixes: #784