Fix Find References for partial members seen through a retargeting assembly

[Demivan]

Fixes #82744

When a project sees another project through a retargeting assembly, uses of partial members bind to retargeting symbols. This happens with a transitive package version skew, with a netstandard2.0 library referenced from netX, and with a Web SDK project whose ASP.NET Core framework reference resolves assemblies that the library's netfx facades forward to. Retargeting symbols expose no PartialDefinitionPart / PartialImplementationPart, by design (#73411, #77203). SymbolEquivalenceComparer required the partial-part flags to match, so Find References, and everything built on it, dropped every use in the referencing project.

Following the review, the partial handling in SymbolEquivalenceComparer is now an option (distinguishPartialParts, on by default). Only SymbolFinder.OriginalSymbolsMatch turns it off, so every other feature keeps the strict comparison.

Once the parts aren't distinguished, a search of either part finds the uses of both, and searching both would report every reference twice. So Find References now treats the parts of a partial member the way it already treats the copies of a symbol in linked files: as the same symbol.

• A new FindSameSymbolsAsync (the linked copies, plus each copy's other partial part) replaces FindLinkedSymbolsAsync in the two places the engine used it: building the SymbolGroup, and expanding the search set. Both declarations stay definitions, and the UI shows them as one entry. SymbolFinder.FindReferencesAsync returns the same ReferencedSymbols as before.
• When cascading, only the definition part is searched, so the interface and override cascade works from either part. A parameter or type parameter named differently in the two parts (CS8826) is the exception and is searched in both, since its uses are spelled with the other name.
• Every cascade between partial parts in the finders is gone (method, property, event, constructor, parameter and method type parameter).

The one visible change in results: uses of a same-name parameter inside the implementation body are now attributed to the definition part's parameter. The set of locations is unchanged.

This also fixes a bug in Implement Explicitly that already existed for linked files. It searched without cascading and took references.FirstOrDefault(). A symbol group reports one ReferencedSymbol per member, but a non-cascading search only searches the starting symbol, so for a member declared in a linked file (for example, in a multi-targeted project), the first ReferencedSymbol could be an empty copy, and the call sites were left unchanged. In a local repro it picked the empty copy in 3 of 5 runs. It now takes the locations from every ReferencedSymbol, which matters for partial members too now that they're grouped.

Tests, in Workspaces.UnitTests unless noted:

• FindReferences_PartialMemberThroughRetargetingReference covers methods, properties and events, searched from either part, through a real project reference (Lib on netstandard2.0, App on netcoreapp). It checks that the cross-project use is attributed to the same definitions as a same-project use.
• FindReferences_PartialMethodCascadesToInterfaceMemberFromEitherPart and FindReferences_PartialMethodParameter cover the hierarchy, a renamed parameter and duplicate references.
• SymbolEquivalenceComparerTests.TestPartialParts (EditorFeatures.UnitTests) covers the option's Equals and GetHashCode.

Tested locally on macOS (net10.0): Workspaces, CSharp.Workspaces, LanguageServer.Protocol, Features and CSharp.Features unit tests pass. The EditorFeatures test projects, which hold the Test2 Find References tests and the Implement Explicitly tests, are net472/WPF and weren't run locally.

🤖 Generated with Claude Code

Microsoft Reviewers: Open in CodeFlow

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Demivan]

@dotnet-policy-service agree

[CyrusNajmabadi]

i would not make these changes. see my recomendation in the issue about an appropriate fix here.

specifically, make all the partial handling logic in SymEquivalenceComparer an option (that find-refs can opt-out of). So from it's perspective, partial is irrelvant, which i think is entirely fine for Find-Refs.

we can also remove the partial-cascading logic from Find-Refs as well.

this then doesn't impact any other features, whihc may want strict correctness in symbol equivalence.

[Demivan]

Done. These changes are dropped: the partial checks are now behind a distinguishPartialParts option that only FAR turns off, and FAR no longer cascades between partial parts. Details are in the updated PR description.