Carry over all applications of repeated Windows Runtime attributes

[Sergio Pedri (Sergio0694)]

Summary

Fixes #2491: when a Windows Runtime type carries the same [allowmultiple] attribute more than once, the projection only kept one of the applications. All applications are now carried over.

Motivation

CustomAttributeFactory.WriteCustomAttributes accumulated the attributes to carry over into a Dictionary<string, List<string>> keyed by the projected attribute's full name, and assigned with attributes[fullAttrName] = args. Windows Runtime attributes marked [allowmultiple] (for instance [TemplateVisualState]) can legitimately be applied several times to the same type, so every application after the first silently overwrote the previous one and was lost from the generated projection.

The issue report shows this with a control declaring eight [TemplateVisualState] attributes in its .idl: the .winmd contains all eight, but the generated C# only carries a single one.

Two adjacent problems in the same method are fixed at the same time:

• Several [ContractVersion] attributes merged their computed platform strings into the argument list of a single [SupportedOSPlatform], which is not a valid constructor shape. Only the first resolved platform is emitted now, which matches the pre-existing member-level behavior in WritePlatformAttributeBody.

• The Windows Runtime [AllowMultiple] metadata attribute has no .NET counterpart: it maps to the AllowMultiple named argument of [AttributeUsage] on the projected attribute type. That mapping only happened when the metadata also carried an [AttributeUsage]. When it didn't, the projected attribute type silently fell back to the .NET default of AllowMultiple = false and could not be applied more than once. An [AttributeUsage(AttributeTargets.All, AllowMultiple = true)] is now synthesized in that case.

Changes

• src/WinRT.Projection.Writer/Factories/CustomAttributeFactory.cs: collect the carried-over attributes into an ordered list with one entry per application instead of a dictionary keyed by attribute name, so repeated applications are all emitted; emit at most one [SupportedOSPlatform]; synthesize an [AttributeUsage] when the metadata only carries [AllowMultiple].

• src/Tests/TestComponentCSharp/TestComponentCSharp.idl: add an [allowmultiple] attribute (MyRepeatableAttribute, attr_repeatable) and a RepeatedAttributeTest runtime class carrying several of its applications, interleaved with a non-repeatable attribute, plus one exact-duplicate application (MIDL accepts those for repeatable attributes, and reflection reports both).

• src/Tests/UnitTest/TestComponentCSharp_Tests.cs: add TestRepeatedAttributesAreProjected, verifying every application survives the projection with the right arguments and that a non-repeatable attribute is still projected exactly once, and TestAllowMultipleIsProjectedOnAttributeUsage, verifying the [AllowMultiple] to AttributeUsage(AllowMultiple = ...) mapping in both directions.

Validation

• Ran cswinrtprojectionrefgen over the entire Windows SDK (reference projection and merged projection modes) and over the full WinUI surface, before and after the change: the generated sources are byte-identical, so no existing projection is affected.

• Built TestComponentCSharp.winmd with MIDL from the new .idl and projected it before and after: the only difference is the newly preserved attribute applications.

• Verified against MIDL that duplicated applications of a non-repeatable attribute are rejected (MIDL2096) while duplicated applications of an [allowmultiple] attribute are accepted and preserved in the .winmd, so the emission is intentionally faithful rather than de-duplicating.

[azure-pipelines]

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

[azure-pipelines]

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