Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Suggestions Ordering #1794

Closed
4e6 opened this issue Jun 10, 2021 · 0 comments
Closed

Implement Suggestions Ordering #1794

4e6 opened this issue Jun 10, 2021 · 0 comments
Assignees
Labels
p-high Should be completed in the next sprint

Comments

@4e6
Copy link
Contributor

4e6 commented Jun 10, 2021

Summary

This task is related to the Doc Chunks #1697. It is about implementing the suggestions ordering designed in the #1698

Value

Suggestions ordering is required by IDE to show module-level documentation in the correct order.

Specification

The task consists of two parts. Extracting the order of module suggestions in the EnsureCompiledJob and preparing the update message in the SuggestionsHandler

EnsureCompiledJob applies user edits, compiles, and indexes (extracts suggestions) from IR.

  • There are two IRs available during the compilation - before and after applying the edits.
  • From both IRs extract a list of suggestions using SuggestionBuilder and filter only the module-level ones (modules, atoms and methods)
  • Given two lists of top-level suggestions. One represents suggestions from the previous compilation run, and the second represents the suggestions after the user edits are applied (current).
    prev: Seq[Suggestion]
    curr: Seq[Suggestion]
    SuggestionBuilder already preserves the order of suggestions in the module. You need to find if the order is changed after applying the user edits.
    Implement SuggestionOrderDiff.compute(prev, curr) method returning the Seq[NodeChange] (see [Suggestion Comparison] section below).
  • Send the Seq[NodeChange] with the SuggestionsDatabaseModuleUpdateNotification.

SuggestionsHandler receives the SuggestionsDatabaseModuleUpdateNotification and applies the updates.

  • Given the Seq[NodeChange], you don't need to store the order in the database, just send it to IDE.

  • Before sending, you need to convert Seq[NodeChange] to Seq[IdChange] where

    class NodeChange(suggestion: Suggestion, prev: Option[Suggestion], next: Option[Suggestion])
    class IdChange(suggestion: Long, prev: Option[Long], next: Option[Long])
    

    IdChange contains ids of corresponding suggestions in the suggestions database (represented by Long).
    You need to implement a method SuggestionsRepo.get(suggestion: Suggestion): Long that finds id of the given suggestion. As an example, take a look at the SuggestionsRepo.remove(Suggestion) method. It also does the lookup but in addition, removes the suggestion.

  • Send the Seq[IdChange] with the SearchProtocol.SuggestionsDatabaseUpdateNotification

  • Document the protocol changes in docs/lanugage-server/protocol-language-server.md

Note. Please come up with better naming. I.e., NodeChange and IdChange names are terrible.

Suggestion Comparison

Unlike the database, suggestions extracted from IR don't have stable ids associated with them. Instead, you can distinguish two suggestions by name, module, kind, and self type (see the SuggestionDiff.compare method). In other words, in the same scope, there can't be two suggestions with the same name, module, kind, and self type.

Example:

In this example two sequences of suggestions represented as lists of integers. Given that (name, module, kind, self type) is unique in the module-level scope, we can go from Seq[Suggestion] to Seq[Int] (just for the purpose of this example). And the problem boils down to finding the difference between two lists of integers.

Given.
prev: [53, 28, 74]
next: [53, 28, 42, 74]
A case when the user adds a new method (42) to the module.

Result.
The algorithm should produce something like that.

[
(53, prev=same, next=same),
(28, prev=same, next=42 ),
(42, prev=28 , next=74 ),
(74, prev=42 , next=same)
]

We represent suggestions order as a linked list with nodes, where

class Node(suggestion: Int, prev: Option[Int], next: Option[Int])`

The algorithm should produce a list of node changes like this.

class NodeChange(suggestion: Int, prev: Option[Int], next: Option[Int])

where Option Some represents that the value has changed, and None that the value stays the same.

Remember that in this example we went from Suggestion to Int as a simplification. Like, you can see that the first suggestion is not changed (53=53). The real algorithm will work with suggestions so that Node and NodeChange will contain Suggestion instead of Int, and you will compare suggestions by name, module, kind, and self type

Acceptance Criteria & Test Cases

IDE receives order updates as a part of suggestions database updates.

@4e6 4e6 added Type: Enhancement p-high Should be completed in the next sprint labels Jun 10, 2021
@wdanilo wdanilo closed this as completed Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p-high Should be completed in the next sprint
Projects
None yet
Development

No branches or pull requests

3 participants