This HLS binary does not support Template Haskell

[why-not-try-calmer]

Your environment

Which OS do you use:
Pop!_OS + Nix.

Steps to reproduce

Launch VSCode with the current (latest) workspace (my project does make use of Template Haskell). All was fine with I think the one before the last version of the extension. It's still mostly fine -- everything works, this annoying popup notwithstanding.

Expected behaviour

No error.

Actual behaviour

This HLS binary does not support Template Haskell.

Include debug information

No 'hie.yaml' found. Try to discover the project type!
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper-1.6.1.0-linux) Version 1.6.1.0, Git revision f4022c5bb8530cd306c53b941878244bf27a5d41 (dirty) x86_64 ghc-8.10.7
Current directory: /home/hades/haskell/feedfarer
Operating system: linux
Arguments: ["--debug"]
Cradle directory: /home/hades/haskell/feedfarer
Cradle type: Stack

Tool versions found on the $PATH
cabal:          Not found
stack:          2.7.3
ghc:            Not found

Consulting the cradle to get project GHC version...
Project GHC version: 8.10.7
haskell-language-server exe candidates: ["haskell-language-server-8.10.7","haskell-language-server"]
Cannot find any haskell-language-server exe, looked for: haskell-language-server-8.10.7, haskell-language-server

[why-not-try-calmer]

As per a related reddit post this seems to be nonspecific to VSCode. Perhaps an Issue to move to the main HLS repo?

[fendor]

Hello, thank you for the bug report!

Yeah, this issue is not VSCode specific, I am going to transfer it so more people notice it :)

[jneira]

@why-not-try-calmer hi, thanks for the report.
That alert was added on purpose cause prebuilt hls binaries dont work with template haskell in a reliable way in general
So maybe in your environment th worked and continue doing so.

• You can see the rationale here (and the long list of linked issues around th): Improve template haskell support (upstream fix and workaround for compiler crashes) #1431
• The issue about adding such alert was: Display a warning when using Template Haskell and static binaries #2391
• And we have opened a general issue about the warning here: Issues around th warning (This HLS binary does not support Template Haskell) and build hls with dynamic linking #2659

[why-not-try-calmer]

@jneira @fendor Thank you very much for your quick and helpful replies. I have two more questions about VSCode, I hope it's not too late to post them here.

As a Linux guy I don't mind compiling stuff but I am a bit concerned about the UX here. I mean, I am using HLS via a VSCode precisely because I want to make the list of things I need to micromanage shorter, not longer. Is there an option to allow VSCode users to not have to worry about this at all, or at least, make the alert more actionable, as in "Hello, you'll need to run <stack build ... | cabal install ...> if you want to fix HLS and make this alert disappear." ?

Also a related but more general question: does that mean that the user is expected to rebuild from source with every update to their HLS VSCode extension?

[jneira]

Is there an option to allow VSCode users to not have to worry about this at all, or at least, make the alert more actionable, as in "Hello, you'll need to run <stack build ... | cabal install ...> if you want to fix HLS and make this alert disappear." ?

Agree with you but the build instructions are complex enough (specially if you want to use more than one ghc version) to not fit an alert i am afraid. You could use cabal, stack or nix or other build system. Now it has a link where you can consult the rationale and instructions:

Screen.Recording.2021-12-11.at.20.47.03.mov

Also a related but more general question: does that mean that the user is expected to rebuild from source with every update to their HLS VSCode extension?

vscode uses a client/server design so update the extension and the server (hls) are separated things.
But you will need to build hls each time a new version of hls (not the extension) is released, if you want the new features and bug fixes, yeah. And we have almost all ide logic in the server.

[jneira]

@why-not-try-calmer if you dont mind i am gonna close this one as we have a general issue about (the mentioned #2659)
This issue has the concrete message in the title and that makes it more discoverable so i am gonna update the title of #2659 to include it, thanks!

[why-not-try-calmer]

I don't mind and your reply makes sense. Thanks!

[why-not-try-calmer]

Oh if I may @jneira perhaps one very last thing: if I am

• a stack user
• interacting from HLS from the HSL VSCode extension

I am not supposed to find any HLS binary on my system except for e.g. ~/.config/Code/User/globalStorage/haskell.haskell, correct?

In which case running stack install haskell-language-server --stack-yaml=stack-${ghcVersion}.yaml --ghc-options="-dynamic" as per the instructions you mentioned (for a stack user) will get me a "duplicated" config, where I'll still have old stuff under ..Code/User.. and have new stuff under ~/.stack.., correct?

Does this entail that manually building + removing leftovers is what I should expect to be doing with every new release from HLS, under the assumptions above? (Honest question, no irony here)

[jneira]

Does this entail that manually building + removing leftovers is what I should expect to be doing with every new release from HLS, under the assumptions above?

well, the vscode extension uses the hls on $PATH as first option and doesnt even try to download it. So after deleting old versions in ..Code/User.. you should not have to do it again, while you keep a hls on $PATH