Haskell-language-server: Provide symbols for workspace/project

Created on 21 Jul 2020  路  10Comments  路  Source: haskell/haskell-language-server

I eventually decided to split in a separate issue (rather than mixing with #215) as I think this may be totally unrelated on second thought.

I am highly unsure of whether this is a HLS, GHCIDE or VS Code thing, please forgive me if it has nothing to do with HLS :sweat_smile:

I notice in VS Code that "Editor symbols" is a thing, e.g. hitting "Go to Symbol in Editor" works.
However hitting "Go to Symbol in Workspace" never works :disappointed: It correctly displays all our Markdown symbols (titles, etc.) but not a single Haskell symbol is displayed not found when I type it (function names, types, etc.).

Is this a bug, a new feature, unrelated to HLS? :grin:

Thank you!

ghcide enhancement

Most helpful comment

Yes, but I need a solid chunk of time to rebase and update it.

All 10 comments

Seems like the request type that needs to be satisfied for this functionality is: https://microsoft.github.io/language-server-protocol/specification#workspace_symbol

I think this would be a really nice feature to have, this would be handled by ghcide though so it might be better to raise the feature request there. I assume it also involves type checking the entire project/module graph, which is something that shake doesn't do at the moment

I think this would be a really nice feature to have, this would be handled by ghcide though so it might be better to raise the feature request there. I assume it also involves type checking the entire project/module graph, which is something that shake doesn't do at the moment

I'm taking a look at it in ghcide at the moment, I've managed to make use of something named knownFilesVar in the Shake data, though whether this reliably provides all filepaths, I haven't yet determined. It'd be nice if so.

Right now it seems promising. I've not handled all cases of building SymbolInformation from the data in each ParsedModule yet, but that's what I'm doing at present.

image

Hi @wz1000, thanks for the insight. Is it possible to build the hiedb-3 branch with stack? I'm not too familiar with cabal and I'm unsure of what's needed to help it resolve the hiedb package.

Am I correct in assuming that since said ghcide branch accounts for the core functionality, the remaining work is the glue necessary for HLS to interface with it (I've completed that on my own fork) and then the hiedb-3 functionality to be merged?

You need to add something like the following to your stack.yaml. For best results, clear your ghcide cache directory(usually ~/.cache/ghcide) before running this branch.

packages:
- .
- location:
    git: https://github.com/wz1000/hiedb.git
    commit: 538f193968aee1a3e5b73a2b1b1ef1c1d36b8c79
  extra-dep: true

This branch is quite close to the one used by hls, so if you can get it to compile, it should work out of the box(including all the new features, you shouldn't have to do anything extra for it).

The branch has a few rough edges, but is getting close to production ready. If you have any more questions, I'm usually available on the #haskell-ide-engine channel on freenode. You can also create an issue on my fork of ghcide.

BTW, your approach seems workable, but I would not advise using GetParsedModule for every module in the project since this would significantly increase memory consumption (since the parsed modules would need to be stored in the Shake graph).

In my branch, all the symbols are stored in a sqlite database, which means we don't need to keep ParsedModules in memory. Also, the database is persisted across ghcide runs.

Thanks so much! I've gotten it to build for 8.8.3, the workspace symbol functionality is working fantastic. Here's my stack.yaml in case anyone else is interested: https://gist.github.com/ix/7fea9de891403c12102f2bea096beed0 :smile:

@wz1000 Will your branch be merged any time?

Yes, but I need a solid chunk of time to rebase and update it.

Was this page helpful?
0 / 5 - 0 ratings