[#1965] Show polymorphic types in LSP + replace generated type variables
Motivation and Context
Problem
If we have polymorphic types in the contract's code then they will be shown as raw ones. E.g.
type 'a t = { x : 'a; y : string }
let x : int t = { x = 42; y = "42" }
On x
hover we'll see { x : int; y : string }
instead of int t
.
Also, generated type variables are printed as gen#123
. It would be
nice if they're displayed like a
, b
, etc.
Solution
Add applied_types
field to the Ast_typed.type_expression
,
preserve them in the 10-checking
pass.
Use Checking.Type_var_name_tbl.t
for providing a pretty type variable
names, do the replacement inside types_pass.ml
.
Related issues
Resolves #1965 (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
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
Show polymorphic values in hovers instead of raw ones. For example, in this code
type 'a t = { x : 'a; y : string }
let x : int t = { x = 42; y = "42" }
on x
hover you'll see int t
instead of { x : int; y : string }
.
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).