ionide / ionide/FsAutoComplete
Expose LSP implementation and call hierarchy support for F# symbols
- Dominant language
- F#
- Stars
- 486
- Forks
- 169
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 5
Description
## Details
I am building a non-IDE semantic client on top of FsAutoComplete. Existing FSAC primitives such as definition, references, workspace symbols, and diagnostics are already useful, but higher-level navigation would make F# codebases much easier to explore from LSP clients and coding agents.
The two missing capabilities I would like to request are standard LSP-style support for:
- `textDocument/implementation`
- `callHierarchy/prepare`, `callHierarchy/incomingCalls`, and `callHierarchy/outgoingCalls`
### Desired behavior
#### `textDocument/implementation`
For F# symbols, return implementing locations for cases such as:
- interface type -> implementing types
- interface member -> concrete member implementations
- abstract member -> overrides/implementations
Results should use the same URI/range conventions as existing FSAC definition/references responses.
#### `callHierarchy/*`
For F# functions and members, support:
- prepare call hierarchy item at a position
- incoming calls: callers grouped by enclosing function/member where possible
- outgoing calls: symbols called from the current function/member where possible
A best-effort implementation would still be useful if some F# constructs cannot be represented perfectly.
### Why this matters
Downstream tools can build agent-friendly summaries and source-context grouping themselves, but they need stable semantic primitives first. Today, clients can approximate this by combining references, symbol uses, and custom source scanning, but that is less reliable than FSAC exposing the standard LSP capabilities directly.
### Scope
This request is intentionally not asking FSAC to produce agent-specific JSON, source snippets, or grouped summaries. Those can live in downstream tools.
The ask here is for standard LSP/tooling primitives that other clients can build on.
### Possible implementation notes
If FSharp.Compiler.Service already exposes enough data, this likely belongs fully in FsAutoComplete as LSP support.
If FCS is missing some compiler facts needed for accurate implementations or call hierarchy, guidance would be helpful on which part should be implemented in FCS first and which part should remain in FSAC.
### Questions
- Does FSAC currently have partial/internal support for `textDocument/implementation` or `callHierarchy/*` that clients can use?
- Would implementing these endpoints align with the project's goals?
- Are there known FCS limitations that would make this infeasible or only approximate?
### Checklist
- [x] I have looked through existing issues to make sure that this feature has not been requested before
- [x] I have provided a descriptive title for this issue
- [x] I am aware that even valid feature requests may be rejected if they do not align with the project's goals
- [x] I or my company would be willing to contribute this feature
Contributor guide
Assessment
This issue has not been assessed yet.