Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Provide symbols for workspace/project #216

Closed
sir4ur0n opened this issue Jul 21, 2020 · 11 comments
Closed

Provide symbols for workspace/project #216

sir4ur0n opened this issue Jul 21, 2020 · 11 comments
Labels

Comments

@sir4ur0n
Copy link
Collaborator

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 😅

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 😞 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? 😁

Thank you!

@jneira jneira added the type: enhancement New feature or request label Jul 23, 2020
@ix
Copy link

ix commented Aug 12, 2020

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

@lukel97
Copy link
Collaborator

lukel97 commented Aug 13, 2020

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

@ix
Copy link

ix commented Aug 15, 2020

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

@wz1000
Copy link
Collaborator

wz1000 commented Aug 15, 2020

@ix
Copy link

ix commented Aug 15, 2020

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?

@wz1000
Copy link
Collaborator

wz1000 commented Aug 15, 2020

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.

@wz1000
Copy link
Collaborator

wz1000 commented Aug 15, 2020

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.

@ix
Copy link

ix commented Aug 15, 2020

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 😄

@expipiplus1
Copy link
Contributor

@wz1000 Will your branch be merged any time?

@wz1000
Copy link
Collaborator

wz1000 commented Oct 28, 2020

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

@jneira
Copy link
Member

jneira commented Feb 24, 2021

Afaics symbols are already provided, cause we merged here a version of the hiedb work started in ghcide.
I can see in our codebase:

workspaceSymbols :: T.Text -> IdeAction (Maybe [SymbolInformation])
workspaceSymbols query = runMaybeT $ do
hiedb <- lift $ asks hiedb
res <- liftIO $ HieDb.searchDef hiedb $ T.unpack query
pure $ mapMaybe AtPoint.defRowToSymbolInfo res

So closing this

@jneira jneira closed this as completed Feb 24, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants