* Fix source spans for multi-clause definitions
Currently, we use the source span of the match which corresponds to
the whole clause instead of just the function identifier. This
resulted in us pointing every goto definition request within a clause
to the function if there is no other information (either because it
failed because it came from an external package or simply because you
are not on an identifier).
This PR fixes this by getting the proper source spans frmo the
HsMatchContext. Somewhat annoyingly, we have to get it from the parsed
module since GHC messes this up during typechecking but it’s
reasonably simple.
* Tests for issue 310 (misleading hover on inner signature)
The most important pair of tests here is the "inner signature" pair. The others
serve mainly to document, compare and contrast what is happening in related
situations.
In summary, hover and gotoDef
+ on inner signatures: give type and location information for the outer
definition; this is misleading,
+ on outer signatures: give no information at all,
+ on inner definitions: give correct information for the inner definition,
+ on outer definitions: give correct information for the outer definition.
Should hover and gotoDef do anything at all for signatures? or is the current
behaviour for outer signatures (doing nothing at all) what we want?
* Require signature hover/gotoDef to point to first clause of definition
* Remove perhaps superfluous tests for definitions
* Fix#248 and #250
This fixes hover for types, classes and type variables.
Information about spans includes a `Maybe Type` which is `Just` for data-level
expressions and `Nothing` for type-level expressions.
`AtPoint.atPoint` which is the oddly-named function responsible for constructing
hover information, runs in the `Maybe` monad, and aborted at the first sight of
a `Nothing`, thus producing no hover information for type-level spans.
In the process of fixing this, I have refactored the function to
+ separate the construction of data-level and type-level hover info
+ make the components that make up the hover info (and their construction) more
clear
I can see plenty little improvements that could be made to the functionality of
the code (and lots that could be made to its organization), but the most
important fixes of the basic missing functionality are here.
Fix#248Fix#250
* Revert behaviour of locationsAtPoint to match its name
The name suggests that it returns all locations, while the last commit changed
this to return at most one.
* Fix issue numbers in test titles
There was some confusion about which tests addressed issue 248 vs 249
Hover and goto definition only work on the function name in the first clause of
a function being defined with multiple equation clauses.
Here are some tests that document this.
* Add tests for issue #237
* Tell hlint to ignore test sample code
* Add test showing similar problem in listcomps
* Identify implementation necessary for test to pass
+ internal class in instance declaration
+ internal class in type signature
+ external class in type signature
Hover seems not to work for classes at all.
Goto def works for internal classes, but not external ones.
This leaves the table looking like this:
| | find definition | hover |
|-------------|-----------|---------|
| field in record definition | ✔️ | ✔️ |
| field in record construction | ❌ | ❌ |
| field name as accessor | ✔️ | ✔️ |
| top level name | ✔️ | ✔️ |
| record data constructor | ❌ | ❌ |
| plain data constructor | ✔️ | ✔️ |
| type constructor | ✔️ | ❌ |
| external type constructor | ❌ | ❌ |
| external value | ❌ | ✔️ |
| plain parameter | ✔️ | ✔️ |
| pattern match name | ✔️ | ✔️ |
| top level operator | ✔️ | ✔️ |
| parameter operator | ✔️ | ✔️ |
| name in backticks | ✔️ | ✔️ |
| class in instance declaration | ✔️ | ❌ |
| class in signature | ✔️ | ❌ |
| external class in signature | ❌ | ❌ |
* Move sample code out into into separate source file
* Add test/data/GotoHover.hs to cabal extra-source-files
* hlint: explicit module export list
* hlint: implement and use readFileUtf8
* hlint: remove -Wmissing-signatures
