Conversation
Adds two small helper assemblies (CrossAssemblyA, CrossAssemblyB) that reproduce the type-dependency structure from issue 1085: - CrossAssemblyA: single-case private DU Did - CrossAssemblyB: Subject DU and TeamMember record whose fields reference Did Three new tests in CodeFormatTests.fs: 1. DU case field shows the actual type name (Did) not obj with absolute hash-r paths 2. Record fields from another assembly show correct names with absolute hash-r paths 3. Same verification works with relative hash-r paths when the script is in the same directory as the referenced assemblies All three tests pass against FCS 43.10.100, confirming the current code-path handles cross-assembly tooltip resolution correctly. The tests serve as regression guards to detect regressions if future FCS or FSharp.Formatting changes re-introduce the issue. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Mar 12, 2026
…strings
On Windows, absolute paths like D:\a\FSharp.Formatting\... contain sequences
such as \F and \a that are invalid or misinterpreted F# string escape sequences
when the path is embedded directly in an F# source string literal passed to
CodeFormatter.ParseAndCheckSource.
Fix: use .Replace('\\', '/') to convert to forward slashes before embedding.
.NET and FCS accept forward slashes in file paths on all platforms.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
Commit pushed:
|
dsyme
approved these changes
Mar 13, 2026
…oltip-tests-3f27d1532f990004
dsyme
approved these changes
Mar 13, 2026
dsyme
deleted the
repo-assist/fix-issue-1085-cross-assembly-tooltip-tests-3f27d1532f990004
branch
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
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.
🤖 This is an automated PR from Repo Assist.
Investigation of issue #1085
This PR adds an end-to-end test infrastructure to investigate and guard against the bug reported in #1085, where hover tooltips in literate F# scripts show
objinstead of the actual type name for types from external assemblies.What I did
I created two small helper assemblies that exactly mirror the type-dependency structure from the issue:
CrossAssemblyA— definestype Did = private | Did of string(a single-case private DU, exactly as in the issue)CrossAssemblyB— references CrossAssemblyA and defines:Subject(DU withAccount of Did)TeamMember(record withDid: Did,Name: string,Active: bool,JoinedAt: DateTimeOffset option)Then I added three regression tests that verify tooltip rendering:
#rpaths —Subject.Account of Didtooltip must containDid, notobj#rpaths —TeamMembertooltip must containDidandDateTimeOffset#rpaths — same verification where the script file lives in the same directory as the referenced DLLs (the user's actual scenario)Key finding
All three tests pass against FCS 43.10.100 (the version used in this repo). The cross-assembly tooltip resolution works correctly when
#rpaths resolve properly (either absolute or relative with the script in the right directory).This strongly suggests the bug in #1085 is:
#r "AssemblyA.dll"without a resolvable path (FCS can't find the file) causes FCS to type-check with incomplete symbol information, leading toobjin tooltips for types it couldn't fully resolve.fsdocs-tool 21.0.0which uses an older FCS; the bug may have been fixed upstream.The tests now serve as regression guards: if a future FCS update or FSharp.Formatting change breaks cross-assembly tooltip resolution, these tests will fail.
Test Status
dotnet build tests/FSharp.CodeFormat.Tests/...)dotnet test tests/FSharp.CodeFormat.Tests/...)dotnet fantomasapplied to all new/modified source filesFiles changed
tests/FSharp.CodeFormat.Tests/files/CrossAssemblyA/CrossAssemblyA.fsprojtests/FSharp.CodeFormat.Tests/files/CrossAssemblyA/Library.fsDidtypetests/FSharp.CodeFormat.Tests/files/CrossAssemblyB/CrossAssemblyB.fsprojtests/FSharp.CodeFormat.Tests/files/CrossAssemblyB/Library.fsSubjectandTeamMembertypestests/FSharp.CodeFormat.Tests/FSharp.CodeFormat.Tests.fsprojProjectReferenceto the two helperstests/FSharp.CodeFormat.Tests/CodeFormatTests.fsRELEASE_NOTES.md[Unreleased]Closes #1085 (investigation; the bug doesn't reproduce in current FCS — tests guard against recurrence).