Skip to content

Track delegate parameter and return types in symbol-based mode#142

Merged
dfederm merged 1 commit intomainfrom
dfederm/fix-delegate-gap
Apr 29, 2026
Merged

Track delegate parameter and return types in symbol-based mode#142
dfederm merged 1 commit intomainfrom
dfederm/fix-delegate-gap

Conversation

@dfederm
Copy link
Copy Markdown
Owner

@dfederm dfederm commented Apr 29, 2026

The symbol-based usage analyzer (ReferenceTrimmerUseSymbolAnalysis=true) missed delegate parameter and return types because the implicitly-declared DelegateInvokeMethod does not fire the SymbolKind.Method action. With a declaration like:

public delegate void Configure(IServiceCollection services);

if IServiceCollection's containing assembly was referenced only through this delegate, RT0002 would falsely flag the reference as removable.

Fix

When the symbol action sees an INamedTypeSymbol with TypeKind.Delegate, walk DelegateInvokeMethod's return type, parameter types, and return-type attributes — mirroring the existing IMethodSymbol branch. (Type-parameter constraints are already covered by the surrounding INamedTypeSymbol case.)

Tests

Adds five regression tests:

  • Delegate with external parameter type (the reported repro)
  • Delegate with external return type
  • Delegate with external generic-argument return type (e.g. List<External>)
  • Generic delegate with external type-parameter constraint
  • Negative: delegate using only same-assembly types does not mark unrelated external assemblies as used

The symbol-based usage analyzer (ReferenceTrimmerUseSymbolAnalysis=true)
missed delegate parameter and return types because the implicitly-declared
DelegateInvokeMethod does not fire the SymbolKind.Method action. With a
declaration like:

    public delegate void Configure(IServiceCollection services);

if IServiceCollection's containing assembly was referenced only through
this delegate, RT0002 would falsely flag the reference as removable.

Fix: when the symbol action sees an INamedTypeSymbol with TypeKind.Delegate,
walk DelegateInvokeMethod's return type, parameter types, and return-type
attributes — mirroring the existing IMethodSymbol branch (type-parameter
constraints are already covered by the surrounding INamedTypeSymbol case).

Adds five regression tests: external parameter type, external return type,
external generic-argument return type, generic delegate with type-parameter
constraint, and a negative test that a delegate using only same-assembly
types does not mark unrelated external assemblies as used.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@dfederm dfederm merged commit 1ea1d85 into main Apr 29, 2026
2 checks passed
@dfederm dfederm deleted the dfederm/fix-delegate-gap branch April 29, 2026 20:58
dfederm added a commit that referenced this pull request Apr 30, 2026
In the symbol-based analysis path, member access via an `override` only
credited the override's containing assembly. The C# compiler validates the
entire override chain at compile time, so any assembly that declares an
overridden base member must remain a reference -- removing it produces
CS0012 errors.

Symbol-based RT, on `IPropertyReferenceOperation` /
`IInvocationOperation` / `IEventReferenceOperation`, walked only
`Member.ContainingAssembly` (= override's assembly) and never visited
`Member.OverriddenProperty?.ContainingAssembly` (= base's assembly), so
the consumer's reference to the base assembly was wrongly flagged RT0002
removable.

Fix: add a `TrackOverriddenChain` helper that walks `OverriddenMethod`
/ `OverriddenProperty` / `OverriddenEvent` chains and tracks every
containing assembly. Call it from the `IInvocationOperation` and
`IMemberReferenceOperation` branches. Fields don't have override chains.

Adds five regression tests that all fail without this change:
- `UsedViaOverridePropertyAccess`: the canonical scenario
- `UsedViaOverrideMethodCall`: method variant
- `UsedViaOverrideEventAccess`: event variant
- `UsedViaOverrideMultiLevelChain`: three-level A -> B -> C chain
- `UnrelatedReferenceNotMarkedByOverride`: negative test ensuring the
  fix doesn't over-credit unrelated assemblies

Different code path from #141 (qualifier tracking on inherited static
member access) and #142 (delegate parameter / return types). Surfaced by
a QuickBuild trial of the symbol-based mode.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dfederm added a commit that referenced this pull request Apr 30, 2026
…145)

In the symbol-based analysis path, only the immediate base type's
containing assembly was credited via `TrackType(namedType.BaseType)`.
The C# compiler validates the entire base-type chain plus implemented
interfaces at type-check time -- CS0012 fires when *any* link's defining
assembly is missing -- so any assembly along the chain must remain a
reference. With `<DisableTransitiveProjectReferences>true</...>`, the
chain doesn't flow transitively, so the consumer must explicitly
reference grandparent assemblies.

Symbol-based RT, when handling `INamedTypeSymbol`, walked only the
immediate `BaseType` and direct `Interfaces`, never recursing further
up. So for `Consumer : Provider` where `Provider : ProviderDependency`
in another assembly, the consumer's reference to `ProviderDependency`
was wrongly flagged RT0002 removable.

Fix: extend `TrackType`'s `INamedTypeSymbol` branch to walk the full
`BaseType` chain and `AllInterfaces` collection. `AllInterfaces` is
broader than `Interfaces` (includes transitively-implemented interfaces)
and mirrors what the compiler validates. A `ConcurrentDictionary<ISymbol,
byte>` keyed via `SymbolEqualityComparer.Default` gates the chain walk
to break self-referential cycles such as `int -> AllInterfaces[IComparable<int>]
-> typeArg int -> ...` and to avoid redundant work.

Adds seven regression tests that all fail without this change:
- `UsedViaInheritedBaseType`: the canonical issue #144 scenario
- `UsedViaImplementedInterface`: interface in the chain
- `UsedViaMultiLevelInheritanceChain`: three-level A <- B <- C
- `UsedViaInheritanceChainOnVariableType`: chain via parameter type
- `UsedViaMixedBaseAndInterfaceChain`: base + interface, four asms
- `UsedViaGenericConstraintBaseChain`: `where T : Provider` constraint
- `UnrelatedReferenceNotMarkedByInheritance`: negative test ensuring
  the fix doesn't over-credit unrelated assemblies

Verified against upstream repro https://github.com/olstakh/RT_Gap_Inheritance:
`Consumer` builds with 0 RT warnings (was emitting RT0002 with v3.5.2).

Different code path from #141 (qualifier tracking on inherited static
member access), #142 (delegate parameter / return types), and #143
(override chains). Same family of "symbol traversal misses a chain"
gaps; same reporter (olstakh).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant