Prelude.head: empty list eval result when main function present

[mattapet]

Your environment

OS: macOS 13.2.1 (22D68)
GHC: 9.8.1, and 9.8.2
LSP: 2.2.0.0, 2.5.0.0, 2.6.0.0, 2.7.0.0, and head
LSP Plugin: hls-eval-plugin

Steps to reproduce

I tried a number of of combinations of GHC/LSP/file setup, but it seems that with GHC 9.8.x any time when there's a main function present in the module, the result after evaluation is Prelude.head: empty list.

E.g.

module Test where

-- >>> 'x'

main :: IO ()
main = putStrLn "Hello World!"

Expected behaviour

module Test where

-- >>> 'x'
-- 'x'

main :: IO ()
main = putStrLn "Hello World!"

Actual behaviour

module Test where

-- >>> 'x'
-- Prelude.head: empty list

main :: IO ()
main = putStrLn "Hello World!"

Debug information

After a bit of debugging myself, I found the error originating from this use of head. After a bit of tinkering, it seems that the underlying hscParsedDecls function, which TyThings output is [Identifier `$trModule'], rather than the expected [Identifier `evalPrint', Identifier `$trModule'].

As the problem seems to arise from the GHC, I am not quite sure whether there's a bug in GHC, or Eval plugin implementation is working under the wrong assumptions.

I am happy to try to fix this if someone is able to provide some additional direction/advice.

[fendor]

Awesome analysis!

Well, the use of head seems worthy of doubt at the very least :)

I can not reproduce the issue with ghc 9.4.8, so some assumption might be violated nowadays.

Can you write a failing test case? I think it is weird that such a trivial example fails, but the hls-eval test suite is green.

I am afraid, I don't have much more insight than that, we currently don't have any active maintainers for this plugin.

[mattapet]

reproduce the issue with ghc 9.4.8

I only now see I forgot to add emphasis this detail 😅 I tried number of GHC version, but the only problematic ones are the one listed, i.e., 9.8.x. I was not able to replicate with prior versions of the GHC.

Can you write a failing test case

Definitely. I created a fork, but can't seem to make it run in the CI. Would you be able to help out with that perhaps?

[fendor]

Just open a PR with your changes against our repo with what you got, that's totally fine. We will allow running the CI on your PR.

[mattapet]

Opened here

[soulomoon]

It is caused by this commit
https://gitlab.haskell.org/soulomoon/ghc/-/commit/3d1d42b76a9ed89ac7735bd357620a03fcfe772a

[soulomoon]

Named NoBackend happened to also be used by haddoc.
The MR that do the commit, https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10469.

addExportFlagsAndRules rely on backendWantsGlobalBindings to check wether we should keep top-level non-export bindings from being optimized away in the Occurrence analysis pass.

We can switch from Named NoBackend to (Named Interpreter) for backend in our plugin which would fix it, but I do not know what side effect it would cause.

---

Oh, it seems (Named Interpreter) is already used in splice plugin.

[mattapet]

Added the ghciBackend to the DynFlags setup for the module here, which seemed to have fixed it locally.