mpickering/ghcide

ghcide analyzes the whole project on startup

Opened this issue · 4 comments

Compare with digital-asset/ghcide which only analyzes the files of interest.

I think this explains the issues that I shared on Friday by email while testing on a codebase with ~5000 modules which takes quite a while to load in this branch

I see but this isn't a bug, it's intentional. It only calls GetModIface on all the targets so the cost should not be too severe if you already have the interface files. I imagine the issue was that this call was never completing because it was getting repeatedly cancelled?

One way to improve this might be to queue all modules in a project individually with low priority rather than one big call which puts them all in the same batch.

Two questions:

  • Why would the initial call to GetModIface on all the targets would be cancelled? What would cancel it?

  • Does hover wait until this call is completed? IIRC you said that it doesn't go through shakeRun, so presumably it can happen concurrently with this call. Would it find any span infos if this call is not completed?

If you look at the logic in exe/Main.hs what should happen is that first the module you requested is loaded, you get IDE features such as hover and then the other modules are loaded.

The request would be cancelled by typing but not by hovering.

I think on the branch you are using there is a potential bug which is stopping hover display earlier. Check that in the FileStore rules you are using a version where all the delayed actions are using GetSpanInfo rather than TypeCheck.