The Fe Language Server project aims to develop a robust, efficient, and feature-rich language server that enhances the development experience for Fe developers. This includes implementing a wide range of Language Server Protocol (LSP) features, improving the backend infrastructure, integrating with the VSCode extension, and thorough testing and documentation.

The language server is being developed against an ongoing Fe compiler rewrite, so it doesn't currently support the version of Fe in the main branch.

An LSP enabled VSCode Extension designed to work with this language server can be found in the editors/vscode directory.

To build the language server binary, run:

cargo build

One straightforward way to interact with the language server during development is to follow the instructions in the Fe VSCode extension readme.

• LSP server crate scaffolding
• LSP-based VSCode extension
• Hover prototype
  • printing debug information
• Basic development setup and documentation
• Orientation, research and study of rust-analyzer and Fe compiler

• Diagnostics publishing prototype
  • using current deprecated diagnostics functionality

• Syntax highlighting in the VSCode extension via Textmate grammar file
• Initial work on transitioning to the new compiler architecture
  • Salsa2022 database setup for language server
  • Overhaul diagnostics types to support types in new compiler crates
  • Working prototype of new diagnostics functionality based on @Y-Nak's name-resolution branch

• Improvements to LSP server + VSCode extension development setup
• Improved document/didChange handling
• Flexible LSP server global logging support using the log crate
• Code style cleanup and linting
• Further work on transitioning to the new compiler overhaul
  • Go-to definition prototype working for standalone .fe files; based on @Y-Nak's compiler rewrite
    • Name resolution from cursor position
    • Snap tests and unit tests for go-to definition functionality
  • Error handling improvements
    • At the time, the rewritten name resolution only supported type resolution in the early resolution stage, but the data types and LSP server implementation should seamlessly support progress on the new compiler's name resolution functionality without many changes

• Research and study of rust-analyzer's file synchronization functionality
• Go-to definition cleanup
• Initial "workspace" functionality
  • a data structure and API for generating, caching and synchronizing necessary salsa inputs to support language server functionality
  • should support file synchronization via filesystem watching and LSP file change events alike
  • Sketch of initial workspace cache data structures
    • Featuring a prefix tree based lookup for salsa inputs representing files, ingots and top-modules
    • Supporting local, external and standalone ingot caches.
  • Upgraded go-to definition functionality to work with "local" ingots containing multiple modules
  • Integration of workspace data structures with existing language server data structures; slight refactor of existing architecture
  • Initial workspace sync prototype and tests
• Initial support for subdiagnostics
• Workspace sync API brainstorming and study

• Improve the internal synchronization API for the "workspace" data structure to support an explicit update step
• Integrated the "workspace" data structure with LSP events and a rudimentary filesystem watcher

• Initial prototype supporting concurrency/task management with tower-lsp

• Big architecture overhaul, switched from tower-lsp to async-lsp
  • much better control over concurrency and event processing order, working around issues described here
  • custom actor implementation supporting lock-free language server state
  • handlers with thread-local futures
• Optional stream-based event handling support
• Multithreaded tracing and logging improvements
• Debounced, multithreaded diagnostics
• TCP support; support for multiple clients
• Organize and prepare server architecture for a variety of LSP features
• Implement a task queue system for long-running tasks
• Enhance hover feature to return useful information and documentation
• Initial work on VSCode extension release pipeline

• Implement progress feedback notifications
• Implement configurable options for the language server
  • Diagnostics configuration
  • Inlay configuration

• Expand go-to feature to support variables, functions, implementations and other references
• Support go-to definitions for Fe standard library
• Improve diagnostics implementation and expand tests
• Autofill and completions
• Import completion
• Refactoring symbol names and file names
• Inlay hints and annotations
• File system navigation
• Show syntax tree, HIR, etc.
• Syntactic and semantic highlighting

• Configurable LSP binary
• VSCode extension release pipeline
  • build setup
  • release pipeline github actions
• Implement configuration and options shortcuts in the VSCode extension
• Investigate support for running tests/proofs from the VSCode extension
• Zed integration

• Better test coverage
• Document the code, architecture, rationale for decisions, risks, and roadmap
• Create a catalog of examples that activate various LSP features

• Look into possibility of supporting proof and Fe test functionality in the language server
• Investigate possible use cases for extending the salsa architecture into the language server more directly, e.g. performance improvements
• View bytecode for selected code
• Code actions for smart contract development
• Would any LSP features be useful for plugging into LLM-based tools? E.g. analytics or descriptions of the codebase?
• Security review and documentation