Add missing Monad constraint in the eval plugin

[sandydoo]

Resolves the following build error when building HLS with GHC 9.2.8 via haskell.nix:

hls-eval-plugin-lib-hls-eval-plugin> src/Ide/Plugin/Eval/Parse/Comments.hs:500:39: error:
hls-eval-plugin-lib-hls-eval-plugin>     • Could not deduce (Monad m) arising from a use of ‘getSourcePos’
hls-eval-plugin-lib-hls-eval-plugin>       from the context: (Ord v, TraversableStream s)
hls-eval-plugin-lib-hls-eval-plugin>         bound by the type signature for:
hls-eval-plugin-lib-hls-eval-plugin>                    getPosition :: forall v s (m :: * -> *).
hls-eval-plugin-lib-hls-eval-plugin>                                   (Ord v, TraversableStream s) =>
hls-eval-plugin-lib-hls-eval-plugin>                                   ParsecT v s m Position
hls-eval-plugin-lib-hls-eval-plugin>         at src/Ide/Plugin/Eval/Parse/Comments.hs:499:1-69
hls-eval-plugin-lib-hls-eval-plugin>       Possible fix:
hls-eval-plugin-lib-hls-eval-plugin>         add (Monad m) to the context of
hls-eval-plugin-lib-hls-eval-plugin>           the type signature for:
hls-eval-plugin-lib-hls-eval-plugin>             getPosition :: forall v s (m :: * -> *).
hls-eval-plugin-lib-hls-eval-plugin>                            (Ord v, TraversableStream s) =>
hls-eval-plugin-lib-hls-eval-plugin>                            ParsecT v s m Position
hls-eval-plugin-lib-hls-eval-plugin>     • In the second argument of ‘(<$>)’, namely ‘getSourcePos’
hls-eval-plugin-lib-hls-eval-plugin>       In the expression: sourcePosToPosition <$> getSourcePos
hls-eval-plugin-lib-hls-eval-plugin>       In an equation for ‘getPosition’:
hls-eval-plugin-lib-hls-eval-plugin>           getPosition = sourcePosToPosition <$> getSourcePos
hls-eval-plugin-lib-hls-eval-plugin>     |
hls-eval-plugin-lib-hls-eval-plugin> 500 | getPosition = sourcePosToPosition <$> getSourcePos
hls-eval-plugin-lib-hls-eval-plugin>     |                                       ^^^^^^^^^^^^

[michaelpj]

Strange that this hasn't come up in our CI, but seems fine if it passes.

[sandydoo]

Strange that this hasn't come up in our CI, but seems fine if it passes.

Yeah, I noticed that as well. Very strange! For posterity's sake, here's a repro: https://gist.github.com/sandydoo/d39597ef8f3f2d71af57bdf4f95feb68

[juhp]

Thanks I just hit this too while trying to update for fedora ghc9.2-9.2.8 (building with cabal).
Is it really due to ghc-9.2.7 vs 9.2.8 or some updated dependency?

((fwiw I also rebuilt it okay the other day for 9.6.2))

edit oh yes I even built 2.0.0.0 with ghc-9.2.8 for Fedora 38 the other day I had forgotten:
so I don't think this was caused by the 32bit alloc fixes in 9.2.8...

[juhp]

If anyone else needs this, this ^^ is how I applied the patch to fedora hls via a local cabal.project build.

[fendor]

I suppose, we were likely not running 9.2.8 in CI? @michaelpj also, this is an example of GHC breaking code in minor versions :)

[juhp]

@fendor well I mentioned above in an edit: - I built 2.0.0.0 with ghc-9.2.8 on Saturday
(before it failed for me), so I am not sure if this is really ghc? or maybe I was lucky??

(CI is already using 9.2.8 though I dunno since when)

[fendor]

Oh, ah, hm. Welp. That's weird. If it happens again, let's do a proper examination.

[kozak]

It also happened for us on ghc 9.2.7:

ghcup install cabal --set && ghcup compile hls --cabal-update --version 2.0.0.0 --ghc 9.2.7 --verbose

Maybe a new release might make sense?