Repository navigation
Answer the Navigate To search that runs while the solution loads - #20492
xperiandri wants to merge 5 commits into
Conversation
✅ Release notes checked
|
ddffeff to
6bf2a72
Compare
T-Gro
left a comment
T-Gro
left a comment
There was a problem hiding this comment.
🤖🕵️ Please shorten the description using this guidance. Focus on the problem and why the change is needed, in simplified technical English. Leave the implementation inventory to the Files tab and retain necessary caveats.
github-project-automation
Bot
moved this from New
to In Progress
in F# Compiler and Tooling
|
Moved out of the PR description per the pr-description guidance — how this was verified, since the branch cannot build in CI yet. Against a local build of Roslyn containing dotnet/roslyn#85213: Checked live as well, with that Roslyn build deployed to the experimental hive: on a 26-project mixed C#/F# solution, breaking in the F# implementation gives the stack |
603ceb0 to
b3b3cdc
Compare
64778a6 to
c14c3f4
Compare
c14c3f4 to
f4ddfd7
Compare
f670007 to
b17a05b
Compare
With no options from the project system yet, the quick parsing options carried no source files, and ParseFile throws looking for the last compiland. Nothing parsed with them before a project had loaded; the Navigate To search that runs during load does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Navigate To runs a search of its own during load, dispatched through `IAdvancedNavigateToSearchService`. F# did not implement it, so every F# project was reported complete and searched not at all, and no full search follows by design — nothing F# declares could be found until the user searched again. The search is a parse away. What it lacked is the project's compilation options, which do not exist yet during load, so `GetFSharpParseResultsAsync` raises. `GetFSharpQuickParseResultsAsync` parses with whatever parsing options the project system has already produced, or defaults: a dictionary read, no reactor, no I/O, which is what makes it safe to call for every document of every project while the solution loads. Those defines can be the wrong ones, and the document's version does not change when the real options arrive, so the version stamp alone would let an approximate parse answer the accurate search: a declaration behind `#if` could be missed, or reported from a branch that never compiles. The cache entry carries whether it was approximate, and the accurate path refuses those, reparsing instead. The loading path takes either, since its contract allows out-of-date results. `SearchCachedDocumentsAsync` follows the shape of the C# and VB service: priority documents and the projects that hold them are searched first, results are reported per document rather than per project so the first ones appear while the rest are still parsing, and each project is reported complete once it is done. The parses of every project take turns on one throttle that leaves a core free, so a search during load cannot take the cores away from the load itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`main` opened 11.0.200 for SDK 11.0.200; 11.0.100 has shipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaying the branch onto main left some files short of the branch's own content; this restores it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…with the collection assert Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
c525021 to
a28b628
Compare
While a solution is loading, Navigate To (Ctrl+T) returned nothing from F# projects, and Roslyn does not repeat the search after loading, so F# declarations stayed missing until the user searched again. F# now implements the loading-time search (dotnet/roslyn#85213) with parse-only results. They may be approximate until project options arrive and are re-parsed accurately afterwards. The search is throttled so it does not slow the load.
Draft: cannot build until the Roslyn dependency includes dotnet/roslyn#85213. Stacked on #20409.
🤖 Generated with Claude Code