Name a declaration from a path-mapped assembly from its root once

[xperiandri]

With a path map in Directory.Build.props, Go To Definition into a sibling project opened generated metadata because the declaration's file name repeated the directory, e.g. .\src\Domain\.\src\Domain\Types.fs. The file name and working directory are now joined only when the directory is rooted. Builds without a path map are unaffected.

Related: #20470 (IDE options) and #20519 (editor resolution). Stacked on #20476.

🤖 Generated with Claude Code

[github-actions]

✅ Release notes checked

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.200.md

[T-Gro]

LGTM

[T-Gro]

🤖🕵️ Please make the description more concise using this guidance. Keep the problem and why the change is needed prominent, using short sentences in simplified technical English. Retain necessary caveats.

[T-Gro]

So shouldn't' this just plain remove .pathMap from tcGlobals and move it over to tcConfig ?

[Copilot]

Copilot review overview

🟡 Changes recommended

A moderate relative-path regression and a duplicate release-note entry remain unresolved.

Review effort: Lite
Findings: 1

Open (1)

• Remove duplicate GetDeclarationLocation release note entry · New

What changed in this PR

Fixes F# declaration paths for path-mapped assemblies and preserves project-specific path maps in cached compiler state.

Changes:

• Corrects mapped source-path resolution.
• Preserves path maps across cached and transparent compilation.
• Adds regression tests and release-note documentation.

File	Summary
tests/​FSharp.Compiler.ComponentTests/​FSharpChecker/​PathMap.fs	Adds path-map regression tests.
tests/​FSharp.Compiler.ComponentTests/​FSharp.Compiler.ComponentTests.fsproj	Includes the new tests.
src/​Compiler/​Symbols/​SymbolHelpers.fs	Adjusts declaration source-path resolution.
src/​Compiler/​Service/​TransparentCompiler.fs	Preserves path maps in transparent compilation.
src/​Compiler/​Service/​IncrementalBuild.fs	Preserves path maps in cached builds.
docs/​release-notes/​.FSharp.Compiler.Service/​11.0.100.md	Documents the fixes; contains a duplicate entry.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes IDE integration executed during design-time.

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

[abonie]

#20518 and #20519 need consistent expectations for the coordinate system of imported filenames: a relative compilation directory does not prove the filename is already root-relative, and a matching suffix does not establish source identity.

An older DLL with #line ... "Original.fs" can require the relative compilation directory to be retained, while ordinary mapped filenames already contain that directory; default deterministic mappings can also produce rooted virtual paths rather than relative names.

Could we pin these distinctions with emitted-DLL tests asserting both the compiler’s returned location and the editor’s destination, rather than relying on in-memory references whose IDE options remove the path map?

[abonie]

An older DLL built with #line ... "Original.fs" and a relative path map can store Original.fs relative to a compilation directory such as .\src\Domain; the new rule discards that directory because it is not rooted, turning a previously resolvable .\src\Domain\Original.fs into Original.fs.

Perhaps retain compilation-directory qualification unless the filename is established to be mapped-root-relative, rather than using the directory’s rootedness as proof that qualification is unnecessary.

An emitted older-producer DLL regression alongside the ordinary mapped-filename case would ensure that removing duplicated directory segments does not also remove a necessary directory component.

[xperiandri]

@abonie Both points are addressed in 1e21fcf.

Rule. A relative file name is now joined with the compile directory unless it already starts with that directory followed by a separator. A path map writes the files compiled from under the directory with the mapped directory at their start, so only such a name is used as is. Everything else keeps the directory, as on main, and your example resolves again: .\src\Domain + Original.fs → .\src\Domain\Original.fs. A rooted directory such as /_/src/Domain can never start a relative name, so /_/ builds behave exactly as on main. One case the rule cannot establish is a mapped name from outside the compile directory, such as a linked file under a relative map. That name is still joined, as on main.

Tests. I replaced the in-memory declaration test with one that compiles the library with fsc out of process from its own directory and references the emitted DLL. It runs with no map, with . and with /_/. For an ordinary file, it asserts what GetDeclarationLocation returns, read back through the map. A current compiler cannot emit the #line case: since F# 10 (#18699) it writes the real file for a #line directive. So the test resolves Original.fs against the emitted assembly's recorded directory, through the same fileNameOfItem step GetDeclarationLocation uses. As a control, main's rule fails the ordinary . case (src\Domain\src\Domain\Library.fs), and the previous revision fails the #line . case (it returns Original.fs).

Editor. The editor's destination is decided in #20519, which this PR does not touch. For /_/ builds, what it receives on Windows is C:\_\src\Domain\Library.fs, because a range turns every rooted name into a full path.

[abonie]

Retaining the compilation directory fixes the bare Original.fs case, but the prefix rule still has an older-producer counterexample. An SDK9 DLL can record a #line filename of .\src\Domain\Original.fs relative to compilation directory .\src\Domain; the current rule resolves root\src\Domain\Original.fs instead of root\src\Domain\src\Domain\Original.fs, and the isolated probe demonstrates the wrong destination even when both files exist. Perhaps cover this matching-prefix case with genuine older-producer metadata and make qualification compatibility-safe rather than treating a directory prefix alone as proof that the filename is mapped-root-relative.

[T-Gro]

🤖 🕵️ Re-reviewed all recent changes as of 5d40d47; 2 findings

[xperiandri]

@abonie Fixed in 75bb45b: a name that starts with the mapped compile directory is used as written only when the item lies in the same file as the outermost module or type around it, and a #line name written by a compiler before F# 10 puts the two in different files, so .\src\Domain + .\src\Domain\Original.fs keeps the directory again. The test a #line name an older compiler wrote keeps the directory that the name of a compiled file already starts with reads PathMapFSharp9.dll, real output of the F# 9 compiler (FSharp.Compiler.Service 43.9.300) for that layout. F# 9 records such a #line name and a mapped file name identically, so where the directive precedes the module header, or the module has a signature file, the two still cannot be told apart and the name is read as a mapped one.

[T-Gro]

The diff is still way too big - apply the NoBloat instructions and CodeCompaction skill.

Especially the massive code comments would benefit not just with drastic reduction, but ideally with well named functions/arguments/bindings/types making the intention clear.

If a well named piece of code just tells what the comment says - delete the comment.

• This diff adds 47 new code comment lines and 3501 new code comment chars.
• Comments bypass the type system and become stale maintenance state. Keep only durable public contracts; express implementation intent through names, functions, active patterns, discriminated unions, and types.