The `T` in `Lazy<T>` is marked `DynamicallyAccessedMemberTypes.PublicParameterlessConstructor`

Open
#112,128 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
csharp
Domain
compilers

Research direction

Start by reviewing the Lazy constructors, especially the default constructor and the factory overload, along with their DynamicallyAccessedMemberTypes annotations. Compare the warning produced for the Create(Func) example with default-constructor usage, and determine whether a scoped annotation can avoid the false positive without regressing trimmed applications that use the default constructor.

Written by the indexing model from the issue text.

Description

area-System.Runtime linkable-framework

This is presumably there to support the default constructor which instantiates default instances via the Activator, but it creates false positives in AOT compatible projects consuming Lazy<T> without using reflection. For example, the following method issues a warning:

static Lazy<T> Create<T>(Func<T> factory) => new(factory);

forcing authors to either suppress the warning or virally add DynamicallyAccessedMemberTypes annotations to every generic method consuming Create. I'm not aware of any workarounds other than marking the default constructor as RequiresUnreferencedCode but presumably this would create regressions in trimmed apps using the default constructor. I'm wondering if there's a way we could specify DynamicallyAccessMembers on a type parameter in a way that is scoped to a particular constructor overload.

cc @vitek-karas @eerhardt for thoughts.

Dominant language
C#
Stars
18.3k
Forks
5.6k
PR merge metrics
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.