Fix ILLink duplicate warnings for generic parameters with new() constraint and PublicParameterlessConstructor annotation

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.

[Copilot]

• Inspect branch state, relevant files, and README guidance
• Fetch full history and latest origin/main
• Merge origin/main into the branch and resolve conflicts in ILLink files
• Validate the resolved branch with targeted ILLink tests
• Review the final diff and report the resolution

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ILLink: extra warning for generic parameter with new constraint and annotation</issue_title>
<issue_description>Repro:

// IL2026 for type (ILLink produces this twice)classClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation:RequiresNewAndConstructors<ClassWithRequires>{// IL2026 (ILLink produces this twice)publicClassWithWarningOnGenericArgumentConstructor_NewAndAnnotation(){}}classRequiresNewAndConstructors<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]T>whereT:new();[RequiresUnreferencedCode("Message for --ClassWithRequires--")]classClassWithRequires;

This produces a warning on the type and on the implicit call to the base constructor (ILLink and ILC both do this). But ILLink produces two of each. That's because:

• ILC handles the new constraint by treating it like PublicParameterlessConstructor annotations
• ILLink handles the new constraint separately, while marking generic argument types
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• FixesILLink: extra warning for generic parameter with new constraint and annotation #119290

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes duplicate IL2026 warnings in ILLink when generic parameters have both a new() constraint and DynamicallyAccessedMembers(PublicParameterlessConstructor) annotation. The issue occurred because both MarkStep.cs and GenericArgumentDataFlow.cs independently marked the default constructor, each producing warnings.

Changes:

• Modified MarkStep.cs to skip marking default constructors for new() constraints when the parameter already has PublicParameterlessConstructor annotation
• Updated test expectations in RequiresOnClass.cs to remove duplicate warning attributes

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs	Added check to avoid duplicate constructor marking when PublicParameterlessConstructor annotation exists
src/tools/illink/test/Mono.Linker.Tests.Cases/RequiresCapability/RequiresOnClass.cs	Removed duplicate ExpectedWarning attributes that were tracking the bug

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/illink
See info in area-owners.md if you want to be subscribed.

[github-actions]

🤖 Copilot Code Review — PR #123457

Note

This review was generated by Copilot.

Holistic Assessment

Motivation: Legitimate bug fix. Issue #119290 documents that ILLink produces duplicate IL2026 warnings when a generic parameter has both a new() constraint and a [DynamicallyAccessedMembers(PublicParameterlessConstructor)] annotation. Two independent code paths (MarkGenericArguments for the new() constraint and GenericArgumentDataFlow for the annotation) both mark and warn about the same constructor.

Approach: Correct and targeted. The fix prevents the new() constraint path from firing in MarkGenericArguments when the annotation path (GenericArgumentDataFlow) will already handle it. This aligns ILLink with ILC's (NativeAOT) approach of treating new() constraints as annotations.

Summary: ✅ LGTM. The fix is small, targeted, and correctly addresses the root cause. The HasFlag check properly handles composite flags. GenericArgumentDataFlow comprehensively covers all access patterns via ReflectionMethodBodyScanner (field accesses, method calls, type tokens), MarkTypeDefinition (base types), and MarkInterfaceImplementation (interfaces), so skipping MarkDefaultConstructor when the annotation subsumes it is safe. Already approved by @sbomer (area owner) and @jtschuster.

---

Detailed Findings

✅ Correctness — Fix properly deduplicates constructor marking

The HasFlag(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor) check correctly handles all relevant flag combinations:

• PublicParameterlessConstructor (0x0001) — exact match
• PublicConstructors (0x0003 = 0x0002 | 0x0001) — superset
• All — includes everything
• None / unrelated flags — returns false, preserving the MarkDefaultConstructor call

When the annotation is present, GenericArgumentDataFlow.ProcessGenericInstantiation both marks the constructor (via RequireDynamicallyAccessedMembersAction → ReflectionMarker) and produces the IL2026 warning, so nothing is lost by skipping the redundant MarkDefaultConstructor call.

The earlier Copilot PR reviewer suggestion to add redundant PublicConstructors and All checks was correctly dismissed — HasFlag already handles composite flags by design.

✅ Data flow coverage — No gap in constructor marking

Verified that GenericArgumentDataFlow.ProcessGenericArgumentDataFlow fires comprehensively across all relevant code paths:

• Base types: MarkStep.cs:2165 (in MarkTypeDefinition)
• Interfaces: MarkStep.cs:4093 (in MarkInterfaceImplementation)
• IL body scanning: ReflectionMethodBodyScanner processes field accesses (line 112), type accesses (144), method accesses (151), field tokens (158), and method calls (199)
• Deferred analysis: TrimAnalysisGenericInstantiationAccessPattern for types, methods, and fields

This ensures that whenever MarkGenericArguments would fire for a generic instance with annotations, the data flow path also fires to handle marking and warnings.

✅ Test changes — Correctly updated expectations

The two removed [ExpectedWarning] lines in RequiresOnClass.cs had Tool.Trimmer scoping and referenced issue #119290, confirming they tracked the exact duplicate warning being fixed. The remaining single [ExpectedWarning] per location correctly expects one warning (from the data flow path). The RequiresNew<T> test case (which has new() only, no annotation) is unchanged, confirming the fix is scoped correctly.

💡 Null safety — Already handled

parameter?.HasDefaultConstructorConstraint == true guarantees parameter is non-null before the block where GetGenericParameterAnnotation(parameter) is called. No concern here.

Generated by Code Review for issue #123457 · ◷

[sbomer]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

The merge conflicts have been resolved. The issue this PR was addressing has already been fixed in the main branch by PR #119419 ("Remove base DAM mismatch warning on types"). That PR removed the entire new() constraint handling code from MarkGenericArguments in MarkStep.cs, which was the root cause of the duplicate warnings.

Since the duplicate warnings no longer occur in the main branch, this PR is no longer needed and can be closed. The branch should be reset to the latest main.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

GetGenericParameterAnnotation(parameter) resolves the generic parameter’s declaring type/method and is now executed for every new()-constrained generic argument. If this ends up on a hot path during linking, you could short-circuit by first checking whether the generic instance’s definition has any generic-parameter annotations (e.g., FlowAnnotations.HasGenericParameterAnnotation on the GenericInstanceType/GenericInstanceMethod) and only calling GetGenericParameterAnnotation when annotations are present.

[sbomer]

Confirmed that #119419 fixed the same issue.