search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.72k stars 368 forks source link

HLS reports non-existent errors when using Calamity and Polysemy with Polysemy.Plugin (polysemy-plugin) #2989

Closed ribosomerocker closed 1 year ago

ribosomerocker commented 2 years ago

haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 1.7.0.0 (GHC: 9.2.2) (PATH: /home/mon/.local/share/ghcup/hls/1.7.0.0/lib/haskell-language-server-1.7.0.0/bin/haskell-language-server-wrapper)
Tool versions found on the $PATH
cabal:          3.6.2.0
stack:          Not found
ghc:            9.2.2

(I launched HLS in the terminal with haskell-language-server-wrapper to provide the errors it reports in the paste below) HLS reports errors that seem to not exist, because building & running the project works, and testing the program results in correct behaviour. I have this paste: https://bpa.st/J32A which has the Main.hs and the errors that HLS thinks exist. The git repository is provided later on in this issue.

Your environment

Which OS do you use: Arch Linux (Artix variant) Which LSP client (editor/plugin) do you use: doom emacs+lsp-mode Describe your project (alternative: link to the project): https://git.sr.ht/~monaaraj/bot

Steps to reproduce

I just run doom emacs and open up my project. This issue happens only with this calamity and polysemy (with polysemy-plugin) project, HLS acts well in every other project I have.

Expected behaviour

The program should be deemed without error, if GHC builds and runs the program, with the program successfully running without issue.

Actual behaviour

HLS reports very very weird errors regarding Internal.Typeable things, P.Member instance overlaps, ambiguous use of type variables... the specific errors have been provided in the bpaste link above.

Include debug information

The HLS log seems to be too long to be pasted to any paste service, so I have provided it as an attachment file: hls.log

MorrowM commented 2 years ago

It's worth pointing out that these are the exact error messages you get from polysemy-plugin not being enabled.

MorrowM commented 2 years ago

It appears this is 9.2 specific. On 8.10.7 and 9.0.2 HLS does not raise any of the errors.

oberblastmeister commented 2 years ago

This also happens with effectful-plugin

michaelpj commented 2 years ago

I think @pepeiborra did the 9.2 compatibility work? Did something change wrt plugins?

sonowz commented 2 years ago

I'm having same issue with polysemy-plugin, and I strongly suggest that HLS does not handle GHC option -fplugin=Polysemy.Plugin correctly. GHC shows the same error as HLS if -fplugin=Polysemy.Plugin option is not given.

Can anyone confirm this behavior?

tek commented 2 years ago

@sonowz that is correct. interestingly, I've been observing this kind of misbehaviour ever since, but only very infrequently. With GHC 9.2, it is now permanent.

PPKFS commented 2 years ago

Completely forgot about this, but I had this issue with Cleff.Plugin some months back. 9.0.x was fine, but any 9.2.x build it would throw up HLS errors.

Ran into it again today when using Effectful.Plugin on 9.2. Again, vanishes if I swap to 9.0. It seems hls on 9.2 simply does not read plugins somehow.

sonowz commented 1 year ago

In my case upgrading to HLS 1.9.0.0 fixed this issue, thanks to #3309. For GHC 9.2.4 Polysemy.Plugin is successfully loaded with HLS 1.9.0.0.

tek commented 1 year ago

same, everything's working now

michaelpj commented 1 year ago

Yep, this should have been fixed in 1.9.0.0.