8b8561a699
This PR improves the 'Go to Definition' UX, specifically: - Using 'Go to Definition' on a type class projection will now extract the specific instances that were involved and provide them as locations to jump to. For example, using 'Go to Definition' on the `toString` of `toString 0` will yield results for `ToString.toString` and `ToString Nat`. - Using 'Go to Definition' on a macro that produces syntax with type class projections will now also extract the specific instances that were involved and provide them as locations to jump to. For example, using 'Go to Definition' on the `+` of `1 + 1` will yield results for `HAdd.hAdd`, `HAdd α α α` and `Add Nat`. - Using 'Go to Declaration' will now provide all the results of 'Go to Definition' in addition to the elaborator and the parser that were involved. For example, using 'Go to Declaration' on the `+` of `1 + 1` will yield results for `HAdd.hAdd`, `HAdd α α α`, `Add Nat`, ``macro_rules | `($x + $y) => ...`` and `infixl:65 " + " => HAdd.hAdd`. - Using 'Go to Type Definition' on a value with a type that contains multiple constants will now provide 'Go to Definition' results for each constant. For example, using 'Go to Type Definition' on `x` for `x : Array Nat` will yield results for `Array` and `Nat`. ### Details 'Go to Definition' for type class projections was first implemented by #1767, but there were still a couple of shortcomings with the implementation. E.g. in order to jump to the instance in `toString 0`, one had to add another space within the application and then use 'Go to Definition' on that, or macros would block instances from being displayed. Then, when the .ilean format was added, most 'Go to Definition' requests were already handled using the .ileans in the watchdog process, and so the file worker never received them to handle them with the semantic information that it has available. This PR resolves most of the issues with the previous implementation and refactors the 'Go to Definition' control flow so that 'Go to Definition' requests are always handled by the file worker, with the watchdog merely using its .ilean position information to update the positions in the response to a more up-to-date state. This is necessary because the file worker obtains its position information from the .oleans, which need to be rebuilt in order to be up-to-date, while the watchdog always receives .ilean update notifications from each active file worker with the current position information in the editor. Finally, all of the 'Go to Definition' code is refactored to be easier to maintain. ### Breaking changes `InfoTree.hoverableInfoAt?` has been generalized to `InfoTree.hoverableInfoAtM?` and now takes a general `filter` argument instead of several boolean flags, as was the case before.
19 lines
899 B
Text
19 lines
899 B
Text
{"textDocument": {"uri": "file:///definition.lean"},
|
|
"position": {"line": 5, "character": 2}}
|
|
[{"targetUri": "file:///definition.lean",
|
|
"targetSelectionRange":
|
|
{"start": {"line": 0, "character": 10}, "end": {"line": 0, "character": 13}},
|
|
"targetRange":
|
|
{"start": {"line": 0, "character": 10}, "end": {"line": 0, "character": 13}},
|
|
"originSelectionRange":
|
|
{"start": {"line": 5, "character": 2}, "end": {"line": 5, "character": 3}}}]
|
|
{"textDocument": {"uri": "file:///definition.lean"},
|
|
"position": {"line": 11, "character": 13}}
|
|
[{"targetUri": "file:///definition.lean",
|
|
"targetSelectionRange":
|
|
{"start": {"line": 11, "character": 4}, "end": {"line": 11, "character": 5}},
|
|
"targetRange":
|
|
{"start": {"line": 11, "character": 4}, "end": {"line": 11, "character": 5}},
|
|
"originSelectionRange":
|
|
{"start": {"line": 11, "character": 13},
|
|
"end": {"line": 11, "character": 14}}}]
|