Don't attach code-fix locations from outside the analyzed compilation

[sbomer]

Fixes #109352

The crash

The DynamicallyAccessedMembers analyzer crashes with AD0001 in Visual Studio when it reports a diagnostic against a symbol that lives in a referenced project:

System.ArgumentException: Reported diagnostic 'IL2075' has a source location in file
'...\MessagePack.Annotations\Attributes.cs', which is not part of the compilation being analyzed.

Root cause

When the analyzer reports a data flow warning, it also attaches an extra location pointing at the declaration of the symbol that should be annotated, so the code fixer knows where to insert the attribute. Roslyn validates that every location on a reported diagnostic — including AdditionalLocations — belongs to the compilation being analyzed, so attaching a declaration from another compilation throws.

Two guards were used to decide whether that extra location was safe to attach, and both are wrong:

Site	Guard
DiagnosticContext.CreateDiagnostic	symbol.DeclaringSyntaxReferences.Length == 0
DynamicallyAccessedMembersAnalyzer.VerifyDamOnMethodsMatch	Location.IsInSource

Both are really asking "is this symbol part of the compilation I am analyzing?", but neither answers that question. Under a CompilationReference — which is how Visual Studio models a project-to-project reference — a symbol from another project is still a source symbol with real declaring syntax references, so both guards happily let the foreign location through.

This is why the crash only reproduced in Visual Studio, and only with "run analysis on unopened files" enabled — which matches the reproduction history on the issue. Command-line builds reference other projects through their emitted assemblies, so cross-project symbols are metadata symbols with no declaring syntax references, and the old guard tripped correctly.

The fix

Replace both guards with Compilation.ContainsSyntaxTree, which asks the question directly.

This requires threading the Compilation into DiagnosticContext. I made it a required constructor parameter rather than an optional one so the compiler points at every construction site — that immediately surfaced three target-typed new(...) sites that a grep for new DiagnosticContext( had missed.

The second guard affects IL2092/IL2093/IL2094. GetTargetAndRequirements picks the base method as the attribute target when an override is annotated and the base is not, so an override in the current project whose base lives in a referenced project hit the same crash. I found this while auditing for other instances of the bug class, and it reproduces independently.

Suppressing the extra location only means the code fix is not offered for declarations the fixer could not have edited anyway. The underlying warning is still reported, and DynamicallyAccessedMembersCodeFixProvider already returns early when there are no additional locations.

Tests

Two regression tests, one per bug site (IL2075 and IL2092). Both were confirmed to fail before the fix with the exact ArgumentException from the issue, and to pass after.

They use TestState.AdditionalProjects / AdditionalProjectReferences, which the Roslyn testing SDK models as a real CompilationReference. Worth noting for anyone testing in this area: the existing ReferenceCompatibilityTestUtils helper cannot reproduce this, because it emits to a stream and creates a MetadataReference.

Full ILLink.RoslynAnalyzer.Tests suite: 1204 passed, 0 failed, 9 skipped.

Other sites audited

I checked the remaining diagnostic sites for the same bug class and believe they are safe:

• RequiresAnalyzerBase — safe by construction; when an interface implementation is inherited from a base class, it already redirects origin to the current type rather than reporting on the base member.
• DynamicallyAccessedMembersTypeHierarchy and ReflectionAccessAnalyzer — only use locations from symbols already established to be within the type being analyzed.

Note

This pull request was created with assistance from GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR fixes a Roslyn analyzer crash caused by reporting diagnostics whose AdditionalLocations point to source files outside the analyzed Compilation (e.g., when the symbol being annotated comes from a referenced project via CompilationReference). The change makes code-fix locations conditional on Compilation.ContainsSyntaxTree(...) and adds regression coverage for both affected diagnostic sites.

Changes:

• Thread Compilation into TrimAnalysis.DiagnosticContext and gate code-fix location attachment on Compilation.ContainsSyntaxTree(...).
• Update all DiagnosticContext construction sites in trim analysis / requires analyzers to pass the active compilation.
• Add regression tests using AdditionalProjects/AdditionalProjectReferences to simulate project-to-project references.

Show a summary per file

File	Description
src/tools/illink/test/ILLink.RoslynAnalyzer.Tests/DynamicallyAccessedMembersAnalyzerTests.cs	Adds regression tests ensuring no foreign AdditionalLocations are attached when the target symbol lives in a referenced project.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TypeNameResolver.cs	Exposes the current compilation internally so downstream trim-analysis helpers can build safe DiagnosticContext instances.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TrimAnalysisReflectionAccessPattern.cs	Passes context.Compilation into DiagnosticContext so code-fix location gating can be compilation-aware.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TrimAnalysisMethodCallPattern.cs	Same as above for method-call pattern diagnostics.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TrimAnalysisFieldAccessPattern.cs	Same as above for field access diagnostics.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TrimAnalysisBackingFieldAccessPattern.cs	Same as above for backing-field access diagnostics.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/RequireDynamicallyAccessedMembersAction.cs	Ensures type-name resolution diagnostics use a compilation-aware DiagnosticContext.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/ReflectionAccessAnalyzer.cs	Updates diagnostic emission paths to construct DiagnosticContext with the correct compilation.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/HandleCallAction.cs	Updates stored/constructed diagnostic contexts to include compilation.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/FeatureCheckReturnValuePattern.cs	Updates diagnostic context creation to include compilation.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/DiagnosticContext.cs	Implements the new compilation-aware guard (ContainsSyntaxTree) before attaching code-fix locations.
src/tools/illink/src/ILLink.RoslynAnalyzer/RequiresAnalyzerBase.cs	Updates diagnostic context creation in implicit base-ctor analysis to pass context.Compilation.
src/tools/illink/src/ILLink.RoslynAnalyzer/DynamicallyAccessedMembersAnalyzer.cs	Replaces Location.IsInSource with a compilation-aware guard for code-fix locations in override/virtual mismatch diagnostics.

Copilot's findings

• Files reviewed: 13/13 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 13/13 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

• Files reviewed: 13/13 changed files
• Comments generated: 0 new

[jtschuster]

LGTM aside from a couple nits.

[agocke]

Heh, I was looking at this as well. Good news -- at first glance I think we have roughly the same implementation.

[agocke]

I think we can stop attaching additional source locations here entirely. Symbols don't need locations because the code fixer can completely hydrate all necessary information without looking at locations at all.

The only place we might need auxiliary information is in data flow.

Same is true for DAM annotations -- on symbols this info is trivial to reconstruct in the fixer. It's only helpful to attach that info for flow analysis, where the fixer would have to re-do all of flow analysis to find the right data.

[sbomer]

Updated to avoid attaching additional locations for the override cases. The fixer will use the additional location when it's set (for dataflow), otherwise it uses the diagnostic location.

[agocke]

Added my version -- these are super similar. I ended up guarding the data flow as well, but then changed overrides to just avoid the problem #131910

Arguably this change is smaller

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/DiagnosticContext.cs:86

• Use the shared DynamicallyAccessedMembersAnalyzer.attributeArgument constant instead of repeating the "attributeArgument" string literal here. This reduces the risk of the analyzer and code fix provider diverging on the property key in future edits.

            {
                DAMArgument.Add("attributeArgument", expectedAnnotationsValue.DynamicallyAccessedMemberTypes.ToString());
                sourceLocation = new Location[] { symbolLocation };

src/tools/illink/src/ILLink.CodeFix/DynamicallyAccessedMembersCodeFixProvider.cs:109

• Solution.GetDocument(SyntaxTree) can pick an arbitrary document when the same file is linked into multiple projects. Since the diagnostic is reported in the current project's compilation, prefer document.Project.GetDocument(targetTree) so the fix is applied in the correct project/document.

            if (targetLocation.SourceTree is not { } targetTree
                || document.Project.Solution.GetDocument(targetTree) is not { } targetDocument)
                return;

• Files reviewed: 16/16 changed files
• Comments generated: 0 new