Fix the GetMany and IndexOf vtable signatures for IVector<T> and IVectorView<T>

[Sergio Pedri (Sergio0694)]

Summary

Fix two IVector<T>/IVectorView<T> vtable slots that were declared with the wrong Windows Runtime ABI signature (GetMany was missing its capacity parameter, and IVectorView<T>.IndexOf was missing its found parameter), and add a validation step to the interop generator so this class of bug can't silently reappear.

The GetMany part of this is extracted out of #2517, where it was needed to unblock the CopyTo optimization. It stands on its own as a correctness fix, so it is split out here to keep that PR focused on the optimization work.

Motivation

Both IVector<T> and IVectorView<T> declare these methods as:

• HRESULT GetMany([in] UINT32 startIndex, [in] UINT32 capacity, [out] T* items, [out, retval] UINT32* actual)
• HRESULT IndexOf([in] T value, [out] UINT32* index, [out, retval] boolean* found)

The declarations of those two vtable slots were missing a parameter each:

• GetMany was missing capacity, in IVectorVftbl, IVectorViewVftbl, and in the specialized vtable types the interop generator emits (via IReadOnlyList1GetManyImpl, which IList1GetManyImpl also reuses).
• IndexOf was missing found, in IVectorViewVftbl and in IReadOnlyList1IndexOfImpl. The IVector<T> counterpart (IList1IndexOfImpl) was already correct, which is why IList<T>.IndexOf works today: it is the only one of these slots that a calli is actually emitted for.

Why no test caught this

Both were completely latent, for the same two reasons:

• Nothing ever called through the slots. No calli is emitted through GetMany for either interface (CopyTo goes through the indexer instead), and IReadOnlyList<T> has no IndexOf member at all, so the IVectorView<T>.IndexOf slot is never called from managed code either. The only slot in this group that is genuinely called through, IVector<T>.IndexOf, had the correct signature.

• The CCW side never validates the slot. Populating a vtable slot is a plain ldftn/stfld pair, which the runtime does not type check, and the implementation methods stored into these slots already had the correct signatures (five parameters for GetMany, four for IndexOf). So native callers were always seeing the correct signature, and the incorrect declaration never influenced any executed code path.

In other words, the declarations were dead weight until something started calling through them, which is exactly what #2517 does. Since the bug is in metadata that no test could observe at run time, the guard added here (rather than a run time test) is what actually closes the gap: it compares the two signatures at the point where they are wired together, so a mismatch fails interop generation instead of silently producing a vtable that only breaks later.

Changes

• src/WinRT.Runtime2/InteropServices/Vtables/IVectorVftbl.cs: add the missing capacity parameter to GetMany.

• src/WinRT.Runtime2/InteropServices/Vtables/IVectorViewVftbl.cs: add the missing capacity parameter to GetMany, and the missing found parameter to IndexOf.

• src/WinRT.Interop.Generator/Factories/WellKnownTypeSignatureFactory.cs: fix IReadOnlyList1GetManyImpl and IReadOnlyList1IndexOfImpl. Now that both declarations agree, IList1IndexOfImpl just reuses the vector view one, as the other identical IVector<T> slots already do.

• src/WinRT.Interop.Generator/Factories/WellKnownTypeDefinitionFactory.cs: update the vtable layout comment for IReadOnlyList1Vftbl to match.

• src/WinRT.Interop.Generator/Helpers/VtableSignatureValidator.cs (new): validates that a vtable slot is declared with the same signature as the method being stored into it. Only the arity and the return type are compared, since the two are allowed to spell an individual parameter differently: shared (i.e. non specialized) vtables use void* where the implementation method uses the exact ABI type of the element, which is ABI identical.

• src/WinRT.Interop.Generator/Builders/InteropTypeDefinitionBuilder.cs: run that validation in Impl, which is the single place where every generated vtable slot is wired to its implementation method. This sits right next to the existing check that all vtable entries are initialized.

• src/WinRT.Generator.Core/Extensions/TypeSignatureExtensions.cs (new) and src/WinRT.Projection.Writer/: move StripByRefAndCustomModifiers out of the projection writer and into the shared generator core (next to the other shared AsmResolver extensions, SignatureComparerExtensions and RuntimeContextExtensions), so the interop generator can use it too.

Validation

All affected projects build clean in Release (where warnings are errors): WinRT.Runtime, WinRT.Generator.Core, WinRT.Projection.Writer, and all five CLI build tools.

Reintroducing either signature bug now fails interop generation for any app using IList<T> or IReadOnlyList<T>, instead of silently emitting a mismatched vtable.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.