HLS not working within GHC (meta improve troubleshooting) #2387
Labels
old_type: meta
Planing and organizing other issues
type: bug
Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
type: enhancement
New feature or request
Comments
|
I'm going to be annoying and not help with the object-level problem (no idea, sorry!) but just list a number of issue-reporting problems that Richard's helpful stream-of-consciousness report made me notice:
|
jneira
added
type: documentation
type: enhancement
|
Hi, thanks for the detailed report. Some notes about the problem itself
To load standalone ghc files hls uses the ghc in PATH, from the report i guess it is ghc-8.10.5 when hls stops to work.
There is an issue about how to handle ghc deprecation in the vscode repo: haskell/vscode-haskell#504. There you can find some workarounds to continue using ghc-8.10.5 while we add support in the extension for ghc versions not supported by the last hls version. Issue here: haskell/vscode-haskell#454 and a pr trying to implement it here: haskell/vscode-haskell#506 |
|
Thanks for this info @jneira. I'm surprised to see that hls-1.5.0 dropped support for ghc-8.10.5, because my understanding of https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html is that ghc-8.10.5 is still supported by hls-1.5.0 -- although deprecated. I would expect, say, a warning at startup saying that dropped support is imminent, but my reading of that table is that ghc-8.10.5 should still work. haskell/vscode-haskell#504 is about ghc-8.10.4, which I read as unsupported by hls-1.5.0, and so I didn't think it was relevant to my situation. Maybe I've just misunderstood the table? And, thanks @michaelpj for extracting out some other meta-items from my post. I did look at the Troubleshooting page (https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html) before filing, but I couldn't find an item on that page that felt actionable. The "Troubleshooting the server" section looks promising, but the different items all talk about executing @michaelpj also says
In Troubleshooting the client, I see some information about getting logs from emacs, but not from VSCode. Am I looking in the wrong place? Full disclosure: I am intentionally not using my sharpest weapon in these explorations. I could, for example, start looking through the VSCode Haskell extension's source code and HLS's source code, learn more about how they all interact, and likely figure all of this out. But I am not doing so, for two reasons: 1. That takes a lot of time! and 2. I am trying to offer myself up as something of a guinea pig to try to improve documentation, etc., so that others have an easier time after me. I am looking at troubleshooting pages and trying to follow actions that present themselves to me, but I'm trying squarely to keep my "intermediate Haskell user" hat on, not my "GHC type-checker grease monkey" hat on. I very much appreciate all the efforts you all are doing in this space -- I hope you see my comments as contributions in an effort to make your work more usable, not as an obstacle! |
|
Oh yeah, I was wrong about the deprecate ghc version and hls-1.5.0 still supports ghc-8.10.5 (its support will be removed in hls-1.6.0). Sorry for the confusion 🤦♂️ |
jneira
changed the title
jneira
added
old_type: meta
|
Ok we have two edges in the issue. Lets handle the meta one. Thanks both for the analysis and suggestion, agree almost completely
In fact https://marketplace.visualstudio.com/items?itemName=haskell.haskell has the readme embedded and it includes the location of the binaries and the mentioned "reporting errors and troubleshooting" section (at the bottom of the page)
The link to vscode has some info on how to extract those logs, could be those instructions improved? EDIT: I've rephrased the issue template to make it clearer More context:
|
|
And now the concrete issue about the hls setup:
I hope now that we could recollect the logs following the vscode troubleshooting section (without waiting to the meta improvements 😉), we would have enough info to trace the cause. |
jneira
removed
the
type: support
|
The instructions in the vscode troubleshooting section were very helpful. Thanks! Here is what I have: At timestamp By the way, thank you thank you thank you for the "meta" stuff listed above. It's energizing to see the attention to detail and your efforts at making this all more accessible. |
|
Hmm maybe the cache about hie files has not been invalidated (you know, the third hardest problem in cs), i would wipe out |
|
Nope -- that's not it: I deleted |
|
@goldfirere uh, i've just being aware the project being loaded seems to be ghc itself ( |
|
Still getting no luck here. I tried doing a Any more ideas? |
|
hmm maybe @mpickering and @wz1000 , who usually works with the ghc codebase could help to know what is still referencing 8.10.5 |
|
There is also the |
|
That made progress. Thanks @wz1000! (I've posted https://gitlab.haskell.org/ghc/ghc/-/issues/20729#note_394247 about getting better cleaning support within GHC.) No more complaining about 8.10.5. But I'm still dead in the water. Here's my latest log: https://gist.github.com/goldfirere/3e41b089560acab9e1acfd9066bc6aaf I don't see any obvious errors there. But e.g. looking up a symbol's definition gets me nowhere. Very much appreciating the help here. I am hoping that we discover a real bug at the bottom of this that's useful to others! |
|
about the meta part: @goldfirere did some interesting suggestions about troubleshooting here: tomjaguarpaw/tilapia#93 /cc @michaelpj just in case find them interesting |
|
Well, for reasons I don't know, HLS is now recognizing GHC. Hooray! I think sometimes restarting VSCode in its entirety actually goes further than just restarting HLS within VSCode. Then, when I switched branches in my git repo, HLS was still using source locations and definitions from the old branch. I don't know how to get it to refresh. (Restarting VSCode does not fix the problem.) I've now had to disable HLS to stop getting wrong answers. :( |
|
hmm maybe both problems are related, cause they are about changes in the project not being refreshed in hls |
|
Wrong symbols and filenames should (at least in my mind) originate from hiedb, since that's basically the main cache layer. It usually re-indexes on file change, but if the project does not compile, e.g. some issue with hie-bios, or something is stuck, or just takes a really long time, then old information is presented. Are there some commits that reproduce this issue reliably? |
|
But all caches were deleted and the source tree cleaned to try to fix the wrong ghc with no luck. @goldfirere do we try the same with this new error related with source files version? maybe they are not directly related and wipe out everything works in this case |
|
Strange tales to tell:
At this point, I expect things to start working in a few days, as happened with both previous problems. But I really don't think I'm doing anything relevant to get it all unstuck! |
|
As it seems solved, can we close this? |
|
@goldfirere I'm trying to make the troubleshooting section more helpful in #2517. I'd appreciate your thoughts, in particular, whether it would have helped you more in its new state. |
|
@Anton-Latukha I do not consider the problem solved, but I also do not have a crisp description of what's going wrong. (An uncrisp description is that the HLS stops working when I change branches.) This may not be actionable, and so closing might be appropriate. But I'm afraid to say I've basically stopped using HLS for GHC development -- grep is just more reliable and is far less likely to distract me from my primary work. My current state is that HLS sometimes stops working, and then after a few days magically works again. This has now happened multiple times. What's odd is that those few days, I've done nothing that appears to be relevant. One such stretch was over a weekend when I didn't touch the computer. Another was when I was consumed with a non-GHC project, and I really didn't touch anything around GHC or HLS. But somehow HLS gets itself unstuck. I wish I had more to offer here. @michaelpj Thanks for revising that page! It's indeed quite helpful now, and I can engage with HLS better. Here are some ideas for further improvement:
My bottom line: For simpler projects / standalone files, I think I could get fairly far with these instructions, and I will consult them when I have a simple case. But I don't yet see how these instructions can help me with GHC. (Again, I know this is an edge case, and the documentation burden may fall on the GHC side of the fence.) Thank you! |
|
Thanks, useful feedback! |
|
Always love such longreads from you. Gives perspective. GHC is of course the kind of a final destination for HLS. Also, the middle layers (plugins & how IDEs handle info) are obscure, with platform-specific multiplying it. Would mention #712 here, as if that is the case - there could be advancements at least in testing/troubleshooting the HLS runs without middle layers to the user (or with minimal middle layer, as https://github.com/mpickering/simple-language-client). From my current reading traversal through the reports seems that current HLS frontier is TH/metaprogramming, so indeed, probably too early to be reliable for GHC dev. |
|
@goldfirere it's a shame that you are not using HLS for ghcide development anymore. Have you investigated whether the Hadrian hie-bios cradle works at all when you change branches? |
|
yeah, I think debug the cradle could help here. The odd thing is afaik @mpickering , @wz1000, @fendor and others are working on ghc, without hitting the issue (I suppose) |
I'm not sure what that means. The file you've linked to exists on the branches I'm switching among, but I don't know what else to do to ascertain whether something is working. Can you give more instructions or point me to some? I don't seem to have Thanks! |
|
yeah sorry, you can install it with |
It's a script that you can run from bash. It invokes Hadrian to build all the dependencies and outputs a set of compiler flags/targets. HLS invokes this script at startup to load the project in a GHC session. This script is completely specific to GHC and the Hadrian build system, so that's the end of my knowledge |
|
I just tried running the Indeed, that environment variable isn't set in my terminal. (Presumably some other tools sets it before calling?) I set it to a file to collect output in and tried again. A lot happens, ending in "Build failed." But actually I think this is a success, as my tree may have a compile error in it at the moment. But HLS still doesn't work when I try to access a definition from within my editor. At this point, debugging HLS is consuming up too much of my precious GHC hacking time. I'm going to officially give up for a little while and then try again in a few months. Thanks much for the time you've spent advising me in this ticket. If there's a takeaway at the end here, I'd say it's this: when things go wrong, please tell the user. Even if (at first) the error message is of dubious quality, at least getting an error would be helpful. Right now, I never quite know if HLS is going to work if I leave it to whir for a few more minutes or if it definitely won't work. Again, thanks for your efforts here and on HLS in general. I look forward to trying again! |
|
@mpickering any improvements needed here for the GHC Hadrian cradle? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Your environment
Output of
haskell-language-server --probe-toolsorhaskell-language-server-wrapper --probe-tools:I don't know. Neither of these executables is on my PATH, and I don't know where they are. HLS was installed by VS Code. I'm pretty sure I saw a notification recently that HLS was being upgraded to 1.5.0. Happy to give you more information if told how to retrieve the information.
Which OS do you use: MacOS
Which lsp-client do you use: VS Code
Describe your project (alternative: link to the project): GHC
Steps to reproduce
Open an editor to a GHC source file, and see that nothing from HLS works.
Expected behaviour
HLS should do stuff, like allow me to jump to a definition, or give me the type of something by pointing at it.
Actual behaviour
Nothing. It's like HLS is off. When I looked at the Problems pane, I briefly saw a message saying (I think) that ghcide was compiled against GHC 8.10.7 while GHC 8.10.5 is the one installed. I can't tell you the error message exactly because it disappeared while I was looking at it. I don't know how to get it back. I have nothing called
ghcidein my PATH.Include debug information
Execute in the root of your project the command
haskell-language-server --debug .and paste the logs here:I don't have
haskell-language-serverin my PATH, and I don't know where it is, so I can't do this. :(Paste the logs from the lsp-client, e.g. for VS Code:
I don't know how to do this. That link did not contain any instructions for how to produce logs for lsp-client.
Other background info
In other work, I did change the GHC in my path several times today, including GHC 8.10.7 for a little while. With GHC 8.10.7, I installed the newest cabal-install. (I would have used GHC 8.10.5, my main version of GHC these days, but I was caught by haskell/network#518, which required using a higher GHC.) But I did nothing with anything called ghcide.
HLS appears to work on non-GHC projects. The GHC tree I'm working in was built bootstrapping from GHC 8.10.5.
I suppose I could just upgrade to GHC 8.10.7. But I have a bunch of trees bootstrapped from GHC 8.10.5, and so doing this would require quite a bit of rebuilding.
Any advice about how to get myself unstuck -- or, even better, how I can learn more about what's going on -- is appreciated. Thanks!
The text was updated successfully, but these errors were encountered: