[#2131] Handle capability modes when declaring capabilities
Motivation and Context
Fixes the language server declaring some capabilities as supported even if they were disabled by the capability mode.
Related issues
Resolves #2131 (closed).
✅ Checklist for the LIGO Language Server
- I checked whether I need to update the
README.md
file for the plugin and did so if necessary:-
If I implemented a new LSP request, I added it to the list of supported features that may be disabled -
If I implemented a new LSP method, I added it to the list of supported functionality
-
-
I checked that my changes work in Emacs, Vim, and Visual Studio Code -
(Before merging) The commit history is squashed and prettified, and follows the Serokell commit policy, or the MR is set to squash the commits
Description
Check commit description.
Component
-
compiler -
website -
webide -
vscode-plugin -
debugger
Types of changes
-
Bug fix (non-breaking change which fixes an issue) -
New feature (non-breaking change which adds functionality) -
Breaking change (fix or feature that would cause existing functionality to not work as expected) -
Performance improvement (non-breaking change that improves performance) -
None (change with no changelog)
Changelog
The LSP server will now correctly declare its list of supported server capabilities in the presence of all capabilities, only semantic tokens, or no semantic tokens flags.
Checklist:
-
Changes follow the existing coding style (use dune @fmt
to check). -
Tests for the changes have been added (for bug fixes / feature). -
Documentation has been updated. -
Changelog description has been added (if appropriate). -
Start titles under ## Changelog
section with #### (if appropriate). -
There is no image or uploaded file in changelog -
Examples in changed behaviour have been added to the changelog (for breaking change / feature).