Skip to content

[#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).

Merge request reports