Fix SourceLink go-to-definition failure when .NET 10 is used on Linux #1441
+41
−14
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When FSharp.Core is built on Linux (as in .NET 10), the PDB contains Linux-style paths. FSAC's getFileName was calling Path.GetFileName on non-Windows, which stripped the directory portion, causing the PDB document lookup to fail. Fix: - getFileName: Keep full FCS path, just normalize backslashes - compareRepoPath: Use suffix matching to handle workspace prefixes
serefarikan
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fix SourceLink go-to-definition failure on .NET 10 for FSharp.Core symbols (e.g.,
List.map).Problem
Go-to-definition fails for FSharp.Core symbols on .NET 10 with error
MissingSourceFile, while working correctly on .NET 9.Root cause: FSharp.Core 10.x is built on Linux (was Windows for 9.x), so PDB paths use forward slashes. On Linux,
Path.GetFileNamecorrectly strips the directory, leaving just the basename (list.fs), which then fails to match the full PDB document path (/__w/1/s/.../list.fs).Changes
getFileName): Keep the full FCS path instead of callingPath.GetFileNameon non-Windows. Just normalize backslashes to forward slashes.compareRepoPath): Use suffix matching - the PDB document should be a suffix of (or equal to) the FCS path, to handle workspace prefixes FCS may add.Tests
mcr.microsoft.com/dotnet/sdk:10.0.100-noble-aot) - go-to-definition onList.mapnow worksmcr.microsoft.com/devcontainers/dotnet:1-9.0) - no regressionDetails
This PR aims to solve the issue described here: ionide/ionide-vscode-fsharp#2115
This has been a very interesting experience because I used claude code to track down the problem, then understand the root cause and implement a fix. I left the comments claude added in the code, because they clarify the context, though for the maintainers of this repo they may be just redundant.
I also tried to track down the changes to how fsharp core libraries are built, which took place with the .NET 10 release, but it is hard to find a single document that explains it. Overall, it looks like the sourcelink document metadata in fsharp dlls have changed. I added some debug statements to trace the document paths
FCSreturns and I can see that .net 9 and .net 10 environments have different values for the same entry:D:\a\_work\1\s\src\FSharp.Core\list.fs/__w/1/s/src/fsharp/src/FSharp.Core/list.fs