[#2056] Better signature items support
- Dec 21, 2023
-
-
Ligo Lang authored
-
Heitor Toledo Lassarote de Paula authored
Draft: [#2056] Better signature items support See merge request !2981
-
Heitor Toledo Lassarote de Paula authored
Problem: A module path can be resolved or not, but we don't properly represent that. Solution: Use a data structure that stores the original path, and also whether that was resolved or not.
-
Heitor Toledo Lassarote de Paula authored
Problem: It's not clear what a declaration, definition, and implementation is. Solution: Add docs trying to clear it up.
-
Heitor Toledo Lassarote de Paula authored
Problem: If we have a definition like `module type T = ...`, and we look for implementers of `T`, we won't see useless information. Solution: Check if we are looking for the implementations of a signature. If so, just return the name of the module implementing that, rather than looking at its defs.
-
Heitor Toledo Lassarote de Paula authored
Problem: We need to check that references work with our changes. Solution: Refactor the test cases a little to avoid boilerplate and add tests for signature items.
-
Heitor Toledo Lassarote de Paula authored
Problem: References for signature items aren't dealt with correctly. This also means that rename and prepare rename don't work as intended. Solution: Refactor some functions from `Go_to_definition` that will be useful for us in `References`. Now, we can find a subgraph of the mod graph that contains all modules that are reachable from one another somehow using the WCC algorithm, and for each module in this graph, get all of its definitions. Now, we can look for the definitions that match the name and level (type, term, module) of the thing we're trying to find a reference for. We change the existing functions in `References` to now deal with finding all references of multiple definitions rather than just one. For `Rename` and `Prepare_rename`, we just reuse the functions defined in `References` to handle the changes.
-
Heitor Toledo Lassarote de Paula authored
Problem: There is a third confusingly named request: go to declaration. The specification doesn't say how this request should be handled, but I think it's fair to make it assume the old behavior of go to definition. Solution: Declare such request in the server, and implement it by simply returning the place where the reference came from. This mimics the old behavior of go to definition. So from a reference, such as `M.x`, we visit `x` within `M`, while in `I.x`, we visit `x` within `I`, while go to definition and go to implementation would behave different for each case.
-
Heitor Toledo Lassarote de Paula authored
Problem: We should now check that definitions and implementations work well. Solution: Refactor the definitions test suite a little and add various tests.
-
Heitor Toledo Lassarote de Paula authored
Problem: Until now, we implemented _go to definition_ without taking signatures and interfaces into consideration. However, we wish to properly deal with signature items in that request, as well as a new _go to implementations_ request. Solution: There are two main parts of the implementation: changes to the definitions pass of scopes, and changes to the go to definition module. In definitions, we keep track of what is a module and what is a signature, and additionally keep track of whatever signatures/interfaces each module/namespace implements. Some creativity was needed here, since the core AST deviates considerably when it comes to the structure of signature definitions and signature expressions. See the relevant comments for more information. In the request for go to definitions, we actually split the logic into two: for definitions and implementations. For definitions, we simply walk the `implements` field of each module, trying to get every relevant definition that matches the current symbol. For implementations, we build a graph with our homemade graph library using signatures as vertices for this graph. This graph is then transposed, so now we can traverse the children of each vertex rather than its parents. We fetch all relevant signatures on the way by cleverly traversing this graph. As a bonus, hovers are now fixed so they can distinguish module types and interfaces from modules and namespaces.
-
Heitor Toledo Lassarote de Paula authored
annotations with includes Problem: `extends` was not recognized as a keyword by the syntax highlighting. Moreover, if an `include` followed some `val`, it would get highlighted as a type. Solution: Add `extends` to the list of JsLIGO keywords. Add `include` to the end of a type definition/annotation. Also, `implements` was duplicate in the list of JsLIGO keywords, so I removed one of them.
-
