Match a path-mapped file name against the solution, not the current directory

[xperiandri]

Go To Definition, Find All References and Rename on a symbol whose assembly was built with a path map
— DeterministicSourcePaths, or a <PathMap> set in Directory.Build.props — open generated
metadata instead of the symbol's source.

Why

A path-mapped assembly names each source file relative to the map's root, and does not record the
root. TryGetDocumentIdFromFSharpRange and FSharpSymbolUse.GetSymbolScope resolved that name with
Path.GetFullPath, that is, against Environment.CurrentDirectory. The current directory belongs to
the process, not to the solution, and holds whatever the last component to set it left there; the
path it produced named a file that does not exist, no document matched, and the symbol was taken for
an external one.

This is the editor half of the path-map fix. #20518 stops the compiler naming the directory twice in
GetDeclarationLocation, which is what reaches the editor in the first place; #20470 keeps the map out
of the options the IDE builds, which covers references between projects held in memory. A referenced
assembly on disk was built by MSBuild with the map, and still carries the mapped names.

The change

Solution.GetDocumentIdsWithFSharpFileName answers which documents a compiler range's file name
denotes:

• a rooted name goes through the workspace's index, as before, so nothing changes for a build without
  a map;
• a relative name is matched by its tail against the paths the solution's documents already have,
  anchored on a separator so that it matches whole directories and never the tail of one. The rule is
  isTheFileAt, which also accepts the doubled separator the compiler writes when the map's
  replacement ends in one (.\ + \src\…).

TryGetDocumentIdFromFSharpRange — Go To Definition, and the declaration document Find All
References starts from, through TryGetDocumentFromFSharpRange — and GetSymbolScope, which decides
the projects Find All References and Rename search, now go through it.

The scan over the solution's documents runs only for a relative name, which means only for a symbol
declared in a path-mapped assembly, and once per navigation: the ranges of the references found are
the solution's own and rooted. Paths are compared case-insensitively; they are not identifiers.

Tests: the rule, including that a name inside a segment matches nothing; and a range whose name a map
left relative finding its document. On the branch this was developed on, running them without the
change fails the second with no document is named by .\Library_…\FileLibrary.fs. On this branch
PathMapNavigationTests pass (9), as do the Go To Definition (3) and Find References (7) tests.

Two lookups in other pending work resolve the same kind of name and need the same rule:
GetSolutionDocumentsWithFilePath in #20462, and the comparison FindSymbolDeclarationInDocument
makes in #20492. Whichever of those merges after this will route through the helper.

Base

Stacked on #20470, which adds PathMapNavigationTests.fs; the diff shrinks to its own commit once
that merges.

🤖 Generated with Claude Code

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes IDE symbol navigation behavior.

Generated by PR Tooling Safety Check · gpt56 1.4M · ◷

[T-Gro]

🤖🕵️ [P1] Find All References loses the consumer's reference when an unrelated document has the mapped suffix. The executed service returns 0 references here; base returns 1. The suffix match selects only Unrelated and bypasses the assembly-reference fallback. Check the defining assembly before restricting the scope.

// C:\package\Library.fs -> ExternalLibrary.dll, --pathmap:C:\package=.
module ExternalLibrary
let value = 42

// Consumer/App.fs; references ExternalLibrary.dll
module Consumer
let result = ExternalLibrary.value // Find All References on value

// Unrelated/Library.fs; separate solution project, no reference to the DLL
module Unrelated
let value = 99

[T-Gro]

🤖🕵️ [P2] Foreign mapped filenames now throw during document lookup on the editor's .NET Framework runtime. An imported DLL carrying this filename previously returned no matches; Path.IsPathRooted now throws before GetFullPathSafe can protect the lookup. Keep invalid/non-native filenames on a non-throwing path.

Imported declaration filename: /home/build/a|b/Library.fs
Base: 0 matching documents
HEAD: System.ArgumentException: Illegal characters in path.

[T-Gro]

🤖🕵️ [P2] Repeated external-declaration lookups add seconds and gigabytes of allocations to Find All References. Project.FindFSharpReferencesAsync resolves the same declaration once per searched project, so a missing mapped source repeats this whole-solution scan. On desktop CLR, 201 lookups over 20,000 documents measured 2.72 s and 1.91 GB allocated, versus 0.37 ms and 32 KB before. Normalize the suffix once and reuse lookup results, including misses, across the search.

// ExternalLibrary.dll was built from Library.fs with --pathmap:C:\package=.\
// Solution: 200 projects, 100 documents each, all referencing that DLL.
// Library.fs is not in the solution. Find All References on value:
let result = ExternalLibrary.value
// Repeated declaration lookup input: .\\Library.fs