ILC warns when it fails to find trimmed-away backing field #119780
Description
We started seeing the following ILC warnings in dotnet/maui#31600:
No warnings expected, but got 1 warnings:
ILC: IL2042: Microsoft.Maui.Controls.RenderWithAttribute.Type: Could not find a unique backing field for property 'Microsoft.Maui.Controls.RenderWithAttribute.Type' to propagate 'DynamicallyAccessedMembersAttribute'.
ILC: IL2042: System.ComponentModel.TypeDescriptionProviderAttribute.TypeName: Could not find a unique backing field for property 'System.ComponentModel.TypeDescriptionProviderAttribute.TypeName' to propagate 'DynamicallyAccessedMembersAttribute'.
Expected: 0
But was: 1
This happens in iOS tests which run ILC on the output of ILLink. The problem is that an ILLink optimization may remove backing fields and rewrite the getter for unreachable code:
.method /* 06000020 */ public hidebysig specialname
instance string get_TypeName () cil managed noinlining
{
.custom instance void [System.Private.CoreLib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (
01 00 00 00
)
// Method begins at RVA 0x21e3
// Header size: 1
// Code size: 11 (0xb)
.maxstack 8
IL_0000: ldstr "Linked away" /* 7000022B */
IL_0005: newobj instance void [System.Private.CoreLib]System.NotSupportedException::.ctor(string) /* 0A000013 */
IL_000a: throw
} // end of method TypeDescriptionProviderAttribute::get_TypeName
And then ILC complains when it can't find a backing field for the getter.
The new warning was added in #119329, but we didn't design for the case where ILLink runs after ILC. This optimization breaks ILC's assumption about how compiler-generated properties should look. I think we should silence the warning in the iOS scenario since that setup (running ILC after ILLink) is somewhat special.
Alternatively, we could probably fix it by removing CompilerGeneratedAttribute when ILLink stubs out the getter, or by just commenting out the ILC warning at https://github.com/dotnet/runtime/pull/119329/files#diff-75dd6efb4bd47819547800323731b3c4e9d4c4c12b40f2d44de124e31d3878a6R606.
@jtschuster @MichalStrehovsky @dotnet/illink
Metadata
Metadata
Assignees
Type
Projects
Status