Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Jan 9, 2026

Description

Removed ~40 API compatibility suppressions from ILLink by making internal implementation types non-public. Many types were unnecessarily public despite not being exposed in the reference assembly.

Changed visibility to internal for:

  • Extension classes: AssemblyDefinitionExtensions, BannedApiExtensions, CustomAttributeArgumentExtensions, MemberReferenceExtensions, MethodDefinitionExtensions, MethodReferenceExtensions, TypeDefinitionExtensions
  • Helper classes: BCL, ConsoleLogger, Driver, TargetRuntimeVersion, FeatureSettings, InternalErrorException, LinkerFatalErrorException
  • Step implementations: AddBypassNGenStep, BodySubstituterStep, CheckSuppressionsDispatcher, CheckSuppressionsStep, CleanStep, CodeRewriterStep, DiscoverOperatorsHandler, DiscoverSerializationHandler, LinkAttributesStep, MarkExportedTypesTarget, OutputStep, OutputWarningSuppressions, ProcessLinkerXmlStepBase, ProcessReferencesStep, ProcessWarningsStep, ReflectionBlockedStep, RegenerateGuidStep, RemoveResourcesStep, RemoveSecurity, ResolveFromXmlStep, RootAssemblyInput, SealerStep, SweepStep, UnreachableBlocksOptimizer, ValidateVirtualMethodAnnotationsStep

Types remain public when:

  • Defined in ref assembly (LinkContext, AnnotationStore, MessageOrigin, MessageContainer, base step interfaces)
  • Used in public API surface (AttributeInfo, AssemblyResolver, EmbeddedXmlInfo, ProcessLinkerXmlBase, parser types)

Customer Impact

None. Internal API cleanup only.

Regression

No - cleanup of existing suppressions.

Testing

Build verification of illink tools.

Risk

Low - purely visibility changes to internal implementation types not exposed in ref assembly.

Original prompt

This section details on the original issue you should resolve

<issue_title>Clean up illink compat suppressions by making types non-public</issue_title>
<issue_description>Many of the types defined in ILLink are unnecessarily public, leading to lots of API compat suppressions. We could clean this up by keeping only those types exposed in the ref assembly as public.

edit: #99467 had a start on this.</issue_description>

<agent_instructions>There are api compat suppressions in src\tools\illink\src\linker\CompatibilitySuppressions.xml. Most of these stem from types that are public, but can be internal instead. First, remove some compat suppressions and build in a way that generates compat warnings. You may need to build from the root of the repo with ./build.cmd tools.illink. Then try to make each public type internal and remove the compat suppression from the xml file. Start with just getting the basic issues out of the way. If you try a few different things and can't remove a suppression, leave it be.</agent_instructions>

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


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@dotnet-policy-service dotnet-policy-service bot added linkable-framework Issues associated with delivering a linker friendly framework labels Jan 9, 2026
Copilot AI changed the title [WIP] Refactor ILLink types to be non-public for better API compatibility Clean up illink compat suppressions by making internal types non-public Jan 9, 2026
Copilot AI requested a review from jtschuster January 9, 2026 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

linkable-framework Issues associated with delivering a linker friendly framework

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Clean up illink compat suppressions by making types non-public

2 participants