search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.05k stars 4.69k forks source link

Don't mark compiler-generated backing fields for reflection in ILLink #102856

Open sbomer opened 4 months ago

sbomer commented 4 months ago

When marking fields for reflection, ILLink usually doesn't treat compiler-generated backing fields specially. They will be marked as any other field if referenced due to DAMT annotations, for example.

However, there is one case where we have an optimization to avoid marking these fields if the corresponding property is not marked - that happens for root descriptors which reference the field using preserve="fields".

There is a similar issue https://github.com/dotnet/runtime/issues/85042 about warnings for reflection access to compiler-generated code, where we decided we would not try to produce warnings in this case. I'm not sure it would be feasible to avoid marking the compiler-generated methods in that case, because I think dependency injection inspects compiler-generated code via reflection.

But we might consider not marking compiler-generated backing fields, as suggested by @jtschuster in https://github.com/dotnet/runtime/pull/102850/files#r1619568383. The current optimization looks for a field name ending with >k__BackingField:https://github.com/dotnet/runtime/blob/e2a46dd6cc6a849c32a4065727f8ce8e32903afa/src/tools/illink/src/linker/Linker.Steps/MarkStep.cs#L2888

Maybe a more robust way to do this would be to look for CompilerGeneratedAttribute on the field.

dotnet-policy-service[bot] commented 4 months ago

Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas See info in area-owners.md if you want to be subscribed.