Skip to content

F# go-to-definition on a BCL type opens a nonexistent file #220

Description

@MelbourneDeveloper

Symptom

Go-to-definition on an imported F# type navigates to a path that does not exist.

  • DateTimeFilePath = "startup", Line = 0
  • List.sumD:\a\_work\1\s\src\fsharp\src\FSharp.Core\list.fsi (a Microsoft build-server path)

The editor opens a file the user does not have. Members are unaffected: DateTime.UtcNow correctly reaches the decompiled System.DateTime.cs:126.

Root cause

src/sidecars/SharpLsp.Sidecar.FSharp/FSharpSemanticNavigation.fs:154-160extractDefinition prefers symbol.DeclarationLocation over FSharpMetadataNavigator.tryResolve. FCS fills DeclarationLocation with rangeStartup for imported entities, so the phantom range wins before the metadata navigator is ever consulted.

A consequence: the FSharpEntity arm at FSharpMetadataNavigator.fs:18 is unreachable dead code.

Fix direction

Consult FSharpMetadataNavigator.tryResolve first for imported symbols, or reject a DeclarationLocation that is rangeStartup / names a file that is not in the workspace, before falling back to it.

Why this matters

CLAUDE.md aim #2 makes F# a first-class citizen. C# go-to-definition decompiles metadata correctly; F# does not for types, so F# is strictly behind here.

Provenance

Found while raising F# sidecar coverage for PR #218 (94.03% → 95.58%). Deliberately not fixed there — adding a failing test would have reddened the coverage gate, and the defect predates that PR.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions