hlint seeking unavailable file /opt/ghc/8.8.4/lib/ghc-8.8.4/settings

[soiamsoNG]

Subject of the issue

hlint seeking unavailabe file /opt/ghc/8.8.4/lib/ghc-8.8.4/settings
and refactor fail since this error

Your environment

Fedora 33, VSCode 1.51

• Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools
  • 0.6
• Which lsp-client do you use
  • vscode
• Describe your project (alternative: link to the project)
  • single hs, no cradle, no cabal
• Contents of hie.yaml
• N/A

Steps to reproduce

1. ghcup install ghc under ~/.ghcup
2. open single hs file
3. apply any hint from hlint
4. prompt of the progress non stop run
5. debug message said /opt/ghc/8.8.4/lib/ghc-8.8.4/settings file not available,
6. symbolic link ~/.ghcup/ghc to /opt/ghc problem fix

Expected behaviour

seeking a correct ghc installed

Actual behaviour

seeking /opt/ghc/8.8.4/lib/ghc-8.8.4/settings

Include debug information

N/A

[jneira]

Thanks for the bug report, it seems the root cause will be the same as #412, so apply-refact might be using ghc-paths (via ghc-exactprint), that store ghc libdir at compile time, making the executable non portable.
Building from source should fix it too.

[jneira]

Opened issue upstream: alanz/ghc-exactprint#96

[ttylec]

On MacOS, in vscode, I get:

/Users/runner/.ghcup/ghc/8.6.5/lib/ghc-8.6.5/settings: openFile: does not exist (No such file or directory)

it looks like some artifact of build process... as vscode plugin uses prebuild binaries.

[polux]

I suspect I'm hitting the same issue ("prompt of the progress non stop run" when applying hlint hints), but I can't find the same error in the HLS logs. After setting a log file and enabling tracing in the vscode extension settings, this is what I get:

2020-11-13 10:22:21.460582604 [ThreadId 367] - finish: applyHint (took 0.00s)
2020-11-13 10:22:21.460604569 [ThreadId 366] - applyHint:apply=[("/tmp/foo/src/Main.hs:7:1-14: Warning: Eta reduce\nFound:\n  foo x = (+ 1) x\nPerhaps:\n  foo = (+ 1)\n",[Replace {rtype = Decl, pos = SrcSpan {startLine = 7, startCol = 1, endLine = 7, endCol = 15}, subts = [("body",SrcSpan {startLine = 7, startCol = 9, endLine = 7, endCol = 13})], orig = "foo = body"}])]
2020-11-13 10:22:21.48032328 [ThreadId 369] - finish: hlint (took 0.00s)
2020-11-13 10:22:21.488593375 [ThreadId 7] - <--2--{"error":{"code":-32603,"message":"ExitFailure 1"},"jsonrpc":"2.0","id":8}
2020-11-13 10:22:21.495215152 [ThreadId 5] - ---> {"jsonrpc":"2.0","id":9,"method":"textDocument/codeAction","params":{"textDocument":{"uri":"file:///tmp/foo/src/Main.hs"},"range":{"start":{"line":6,"character":13},"end":{"line":6,"character":13}},"context":{"diagnostics":[{"range":{"start":{"line":6,"character":0},"end":{"line":6,"character":14}},"message":"/tmp/foo/src/Main.hs:7:1-14: Warning: Eta reduce\nFound:\n  foo x = (+ 1) x\nPerhaps:\n  foo = (+ 1)\n","severity":3,"code":"refact:Eta reduce","source":"hlint"}]}}}

I'm using v1.2.0 of the extension, with hls 0.6 downloaded by the extension. The project is a minimalist stack project for lts-16.21 (ghc 8.8.4).

Should I open a new issue or maybe enable more logging somewhere to confirm this is the same bug?

[jneira]

@ttylec yeah the hls executable is statically linked and it supposes that if some lib assumes the path to ghc is the compile time one, its calls will fail, making the executable partially non portable

@polux the error is present for other users, the unique option for enable logging is -d (you can see what options are enabled in the log, when the server is started)
you can try to apply the workaround, symlinking /Users/runner/.ghcup/ghc/${ghcVersion}/lib/ghc-${ghcVersion} to /path/to/your/ghc-${version}
(or compiling the server from source)

[polux]

@jneira is there a way to pass an option to HLS from the vscode settings? I'd like to check that I'm hitting the same bug and not another one.

[jneira]

@polux yeah, you can enable logging in the extension settings:

[polux]

@jneira sorry if I'm being slow, I don't know much about vscode. I had already enabled that option, which was the reason (I think) I was seeing the <--2-- and ---> in the logs. But apart from seeing these additional messages in the log, I haven't noticed any new output of any kind in vscode itself, let alone any message about /opt/ghc/8.8.4/lib/ghc-8.8.4/settings being not available. Where should I be able to observe this message after activating the option?

[jneira]

@polux dont worry, you can check the log in: Menu View -> Show output -> Choose Haskell(your_project) in the combo

Remove the log file setting to see all possible output in that pane.

If you dont see /opt/ghc/8.8.4/lib/ghc-8.8.4/settings file not available , it likely would be anothe issue.

[polux]

I do see /opt/ghc/8.8.4/lib/ghc-8.8.4/settings: openFile: does not exist (No such file or directory) now. Thanks!

[jul1u5]

I have a similar issue on NixOS:

Missing file: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-ghc-8.10.2/lib/ghc-8.10.2/settings

I can't really create a symlink in this directory, are there any other workarounds?

[jneira]

@jul1u5 i am afraid the unique workaround would be building hls from source, if you dont move the ghc used to build it afterwards, it should work.

[jul1u5]

I found that by using Nix package with attribute haskellPackages.haskell-language-server (instead of haskell-language-server) hlint suggestions actually work!

[shmish111]

@jul1u5 were you using haskell.nix and a nix shell? I'm trying to work out how to fix this, can I add haskell-language-server to my shell.nix and get vscode to use that?

[jul1u5]

@shmish111 I haven't tried using haskell.nix. For VS Code to use environment from shell.nix I found this extension works fairly well.

[garethrowlands]

On my Mac, I got hlint complaining about this file being missing:

/Users/runner/.ghcup/ghc/8.10.2/lib/ghc-8.10.2/settings

My rather crude workaround was to symlink /Users/runner/.ghcup to my ~/.ghcup

[shmish111]

thanks @jul1u5 looks good

[polux]

This was fixed but is happening again to me with the latest version of hls (haskell-language-server-1.0.0-linux-8.10.4):

Missing file: /home/runner/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/settings

[jneira]

will investigate asap

[jneira]

@polux had you the opportunity of trying the workaround mentioned above (#591 (comment))?

[polux]

@jneira yes the workaround works (but forces me to create a runner directory under home).

[jneira]

yeah it is very inconvenient, only want to confirm it continues working and you were aware

[polux]

Sure, didn't mean to sound dismissive. Thank you for pointing out a workaround!

[jneira]

Sure, didn't mean to sound dismissive

no worries it did not sound for me

btw maybe there is another workaround with other drawbacks that may work: setting the GHC_EXACTPRINT_GHC_LIBDIR en var to point to the real /path/to/your/ghc-8.10.4/settings path, instead creating the symlink

See

haskell-language-server/plugins/hls-hlint-plugin/src/Ide/Plugin/Hlint.hs

Lines 410 to 412 in 9f8a172

	let withRuntimeLibdir :: IO a -> IO a
	withRuntimeLibdir = bracket_ (setEnv key $ topDir dflags) (unsetEnv key)
	where key = "GHC_EXACTPRINT_GHC_LIBDIR"

for the code that "explains" the workaround.

If anyone has the opportunity of trying it (and it is more convenient that creating the symlink for you of course) it would help to debug the regression

[polux]

It works for me. I haven't played around long enough yet to verify that it doesn't break other functionalities. Note: I had to set the env variable to /home/polux/.ghcup/ghc/8.10.4/lib/ghc-8.10.4, not /home/polux/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/settings.

[lylek]

Just wanted to point out that although the tag says OS: Linux, this isn’t specific to Linux. I’m having the problem on macOS with HLS 1.0.0. Was able to apply the symlink workaround.

[jneira]

yeah, thanks for noting it, we had a similar issue for Windows too, removing the label

[jneira]

I've opened a pr that should fix the issue (i've tried it locally after reproducing the error): #1451
Thanks all for take time to report the issue again

[2jacobtan]

I've been facing the same issue.

2021-05-13 20:05:55.9800368 [ThreadId 2070] INFO hls:	finish: applyHint (took 0.00s)
[Error - 8:05:55 PM] haskell-lsp:incoming message parse error. {"jsonrpc":"2.0","id":9,"result":null} Error in $.result: parsing () failed, expected Array, but encountered Null

2021-05-13 20:05:55.9800509 [ThreadId 2069] INFO hls:	applyHint:apply=[[Replace {rtype = Decl, pos = SrcSpan {startLine = 33, startCol = 1, endLine = 33, endCol = 14}, subts = [("body",SrcSpan {startLine = 33, startCol = 10, endLine = 33, endCol = 12}),("a",SrcSpan {startLine = 33, startCol = 4, endLine = 33, endCol = 5})], orig = "hl a = body"}]]
2021-05-13 20:05:55.9834096 [ThreadId 2072] INFO hls:	finish: applyHint (took 0.00s)
2021-05-13 20:05:55.983511 [ThreadId 2074] INFO hls:	finish: applyHint (took 0.00s)
2021-05-13 20:05:55.9836457 [ThreadId 2076] INFO hls:	finish: applyHint (took 0.00s)
Missing file: /home/runner/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/settings
2021-05-13 20:05:55.9838856 [ThreadId 2066] ERROR hls:	Unexpected exception on request, please report!
Exception: ExitFailure 1
[Error - 8:05:55 PM] Request workspace/executeCommand failed.
  Message: ExitFailure 1
  Code: -32603 

The symlink trick (#591 (comment)) worked:

Workaround (assumes ghcup is installed):

sudo mkdir /home/runner
sudo ln -sv ~/.ghcup /home/runner/.ghcup

---

Using VSCode Haskell extension, latest version (v1.4.0).
On WSL2 Ubuntu.

haskell-language-server version: 1.0.0.0 (GHC: 8.10.4) (PATH: /home/jt2/.ghcup/bin/haskell-language-server-wrapper-1.0.0) (GIT hash: 4cd1cf934638881e52b3eba9f70157a4b799c0e9)
Tool versions found on the $PATH
cabal:          3.4.0.0
stack:          2.7.1
ghc:            8.10.4

[jneira]

@2jacobtan hi! that bug should be fixed for hls 1.1.0.0, so i would suggest to upgrade it

[2jacobtan]

I've upgraded using ghcup tui, and it is indeed working correctly now, without the workaround.

Thank you @jneira !!

---

Extra info for other readers:

I looked at VSCode output for the Haskell extension, and realised it was indeed using the older HLS version I had installed.

Mistakenly assumed the VSCode extension would automatically download and use the latest HLS version.

But actually:

Note that if haskell-language-server-wrapper/haskell-language-server is already on the PATH, then the extension will launch it directly instead of downloading binaries.

https://github.com/haskell/vscode-haskell/tree/a09c9be206782ab8e35ffe973eae273d7f15205d

[jneira]

Happy to know it is working for you and thanks for the note, it will be useful for future readers