## Description
This PR refactors most of the code that was in `server.rs`.
Specifically, the call backs have been moved to
`handlers/notification.rs` and `handlers/request.rs`. This was inspired
by `rust-analyzer`s approach.
the `server.rs` module now looks like:
```rust
#[tower_lsp::async_trait]
impl LanguageServer for ServerState {
async fn initialize(&self, params: InitializeParams) -> Result<InitializeResult> {
request::handle_initialize(self, params)
}
async fn shutdown(&self) -> Result<()> {
self.shutdown_server()
}
async fn did_open(&self, params: DidOpenTextDocumentParams) {
notification::handle_did_open_text_document(self, params).await;
}
async fn did_change(&self, params: DidChangeTextDocumentParams) {
notification::handle_did_change_text_document(self, params).await;
}
async fn did_save(&self, params: DidSaveTextDocumentParams) {
notification::handle_did_save_text_document(self, params).await;
}
async fn did_change_watched_files(&self, params: DidChangeWatchedFilesParams) {
notification::handle_did_change_watched_files(self, params).await;
}
async fn hover(&self, params: HoverParams) -> Result<Option<Hover>> {
request::handle_hover(self, params)
}
async fn code_action(&self, params: CodeActionParams) -> Result<Option<CodeActionResponse>> {
request::handle_code_action(self, params)
}
async fn code_lens(&self, params: CodeLensParams) -> Result<Option<Vec<CodeLens>>> {
request::handle_code_lens(self, params)
}
etc ...
}
```
A new type called `ServerState` now holds the config, keyword docs,
client and the map of sessions. No new functionality has been added
apart from refactoring the code.
This is needed for the new event loop, I decided to separate that into a
follow up PR to make things a bit more manageable.
closes#4672
## Description
Closes https://github.com/FuelLabs/sway/issues/4645
This PR lets the user generate doc comments for ABI methods. Previously
it was working for functions and function implementations of ABI/trait,
but not on the ABI/trait definition itself.
Since the output is exactly the same for FunctionDecl to TraitFn, I
wanted to do this in a way where they could share the code. I ended up
writing a trait called `FunctionSignature` that both types implement
that exposes `parameters()` and `return_type()`. This allows me to use
the same code for code actions and I suspect it will come in handy in
the future.
One problem was that `FunctionDecl`'s return_type was `TypeArgument`
while `TraitFn` had its return type as `TypeId` with an additional
`return_type_span` field. I changed it so that `TraitFn`'s return_type
is now `TypeArgument` and removed `return_type_span`.
I also needed to add a `span` field to `TraitFn` since previously its
`span()` was returning only the span of the function name, not the whole
function. From what I could see, this doesn't impact the spans of any
existing errors.
### Testing
I added an integration test to the LSP for this scenario.
### Example
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Closes https://github.com/FuelLabs/sway/issues/4571
Following the directory structure for code actions that was there
before, I've added new modules for:
- function decls
- enum variants
- storage fields
- configurable constants
Following https://github.com/FuelLabs/sway-standards/issues/5, the doc
comment template is the same for all of these except for functions. For
functions, the template includes the argument names & types, return
value, and a generated example of usage which is just meant to be a
starting point for the comment author.
For the basic template that most of these use, I created
`BasicDocCommentCodeAction`. I also refactored some of the "generate
impl" code actions that were there before into a trait called
`GenerateImplCodeAction` to keep their common functionality separate
from the "generate doc comment" code actions.
I updated the existing code action tests for enums & structs, and added
a new one for functions. I didn't think it was necessary to test enum
variants, storage fields, etc. since the template and underlying code is
the same.
### Example generating docs for a function
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
