You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 18, 2021. It is now read-only.
Code folding: This should be pretty easy - just walk over any "large" definitions and offer to fold them to a single line.
Type at cursor/Type tooltip.
Completion
Document highlight: This should just be composed of "find this symbol" and then "walk the entire resolved tree".
Go to definition: The nicest approach to this might be to augment names with the position at which they were defined.
Explain error at point:
This will either involve embedding the explanation information within the language server, or shelling out to "amc explain". Note, this will require explicit support within the editor.
Editor-specific support for code lens: F♯/Ionide has custom handling for type-signature overlays, which renders the signature to the side (taking up less vertical space and looking nicer). If the editor doesn't support this extension, it gracefully falls back to normal code lenses.
Workspace symbol: We'd need to parse every file in the project root, and then gather all symbols defined in them.
One thing to be aware of is the complexities in mapping locations back to the typed AST. Typing and desugaring introduces additional nodes, so we need to be careful that what we point to is the correct definition.
Minor cleanup
Split the code lens functionality into provider and resolver. This should also fix problems with showing signatures on classes/instances.
Add a configuration option to disable "type signature code lens" support.
Improve reporting of erroring imports. Ideally we'd give some hint on why an import failed.
Add some input debouncing. This should be disabled by default, and configured by the client.
Write tests for everything.
Further notes
The compiler is currently very much structured in a fail fast manner. Resolution (and TC to a lesser extent) either succeed, or fail and throw away all information. This is obviously not ideal as far as editing goes, as you are rarely operating on a well-formed tree.
There's a couple of things we could do to improve this:
Make parsing more fault-tolerant. It's really not clear how to do this using Happy, and I don't really fancy home-growing another parser generator. There's some interesting notes in this document, which basically distils what things like Roslyn.
Resolution could definitely return an unresolved tree - we already do something similar with junkVar. If we were really fancy, we could even parse such a tree off to TC, and make it smart enough to skip unresolved nodes.
Some operations can operate on older versions of the tree - we just need a function to map positions between old and current locations.
Some elements of verification could be done earlier (foreign parse errors only needs the parsed tree, unused variables could be done within resolve).
The text was updated successfully, but these errors were encountered:
Now that v3.15 of the protocol has been released, it'd be worth adding support for diagnostic tags. This is used in VS Code to render unused variables and deprecated variables in specific ways.
We'll need to submit a PR to haskell-lsp in order to enable that. I put something together when the spec was a draft, but that needs finishing off and pushing.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Features
Code folding: This should be pretty easy - just walk over any "large" definitions and offer to fold them to a single line.
Type at cursor/Type tooltip.
Completion
Document highlight: This should just be composed of "find this symbol" and then "walk the entire resolved tree".
Go to definition: The nicest approach to this might be to augment names with the position at which they were defined.
Explain error at point:
This will either involve embedding the explanation information within the language server, or shelling out to "amc explain". Note, this will require explicit support within the editor.
Editor-specific support for code lens: F♯/Ionide has custom handling for type-signature overlays, which renders the signature to the side (taking up less vertical space and looking nicer). If the editor doesn't support this extension, it gracefully falls back to normal code lenses.
Workspace symbol: We'd need to parse every file in the project root, and then gather all symbols defined in them.
One thing to be aware of is the complexities in mapping locations back to the typed AST. Typing and desugaring introduces additional nodes, so we need to be careful that what we point to is the correct definition.
Minor cleanup
Further notes
The compiler is currently very much structured in a fail fast manner. Resolution (and TC to a lesser extent) either succeed, or fail and throw away all information. This is obviously not ideal as far as editing goes, as you are rarely operating on a well-formed tree.
There's a couple of things we could do to improve this:
Make parsing more fault-tolerant. It's really not clear how to do this using Happy, and I don't really fancy home-growing another parser generator. There's some interesting notes in this document, which basically distils what things like Roslyn.
Resolution could definitely return an unresolved tree - we already do something similar with
junkVar
. If we were really fancy, we could even parse such a tree off to TC, and make it smart enough to skip unresolved nodes.Some operations can operate on older versions of the tree - we just need a function to map positions between old and current locations.
Some elements of verification could be done earlier (foreign parse errors only needs the parsed tree, unused variables could be done within resolve).
The text was updated successfully, but these errors were encountered: