Cant load exe/test/bench module wit stack if the library has not been built previously

[tomasaschan]

I have a project that initializes fine with this extension, but it doesn't seem like I've gotten all the config right yet.

https://github.com/dandeliondeathray/niancat-haskell

When opening src/app/Main.hs I get squigglies about niancat-0.1.0.0 (my library package), and if I open a test file I get squigglies about hspec (referenced in the test package only, not the library).

It seems like the GHCi instance used for tooltips etc is initialized with only the library, and not tests and exe parts, loaded, despite the existence of a hie.yaml which points to the root directories of the different parts.

What am I doing wrong?

[fendor]

I am sorry, the link does not point anywhere, could you correct the link?

[tomasaschan]

@fendor Sorry, didn't realize that org creates private repos by default. Changed it to public now - could you try again?

[pjonsson]

Edit: I misunderstood the context so my comment does not apply, please ignore this.

[fendor]

With cabal, everything works fine for me. (except for hspec-discover not being on my path)
With stack, it fails, though:

> stack repl niancat:exe:niancat-exe 
Stack has not been tested with GHC versions above 8.6, and using 8.8.3, this may fail
Stack has not been tested with Cabal versions above 2.4, but version 3.0.1.0 was found, this may fail
Using main module: 1. Package `niancat' component niancat:exe:niancat-exe with main-is file: /home/munin/Documents/haskell/niancat-haskell/src/app/Main.hs
Building all executables for `niancat' once. After a successful build of all of them, only specified executables will be rebuilt.
niancat> configure (lib + exe)
Configuring niancat-0.1.0.0...
niancat> initial-build-steps (lib + exe)
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: niancat
GHCi, version 8.8.3: https://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package niancat-0.1.0.0
    (use -v for more information)

can you confirm this behaviour? If yes, I suggest that this is a stack bug.

[tomasaschan]

@fendor Yes, I see the same thing:

$ stack repl niancat:exe:niancat-exe
Using main module: 1. Package `niancat' component niancat:exe:niancat-exe with main-is file: /workspaces/niancat-haskell/src/app/Main.hs
Building all executables for `niancat' once. After a successful build of all of them, only specified executables will be rebuilt.
niancat> configure (lib + exe)
Configuring niancat-0.1.0.0...
niancat> initial-build-steps (lib + exe)
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: niancat
GHCi, version 8.8.3: https://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package niancat-0.1.0.0
    (use -v for more information)
$ stack --version
Version 2.3.3, Git revision cb44d51bed48b723a5deb08c3348c0b3ccfc437e x86_64 hpack-0.33.0

How/where do I report this to Stack, if it is indeed a Stack bug? And what do you think is the minimal stuff needed to reproduce this, if I want to put together a minimal reproduction first (I don't think I understand the issue well enough yet to do that...)?

[fendor]

Report at their main repo: https://github.com/commercialhaskell/stack/issues

About minimal, I would not worry for now. Just post the issue with the example project.
You could try to simplify it by copying the project structure but deleting everything else. E.g. library only has a single trivial module, the executable has one trivial main that depends on the library, and all other executables and tests are stripped down the same way. If this reproduces the problem, I would say that is small enough.

[tomasaschan]

Interestingly, that did not reproduce... 🤔 Here's the repo where I'll build a repro: https://github.com/tomasaschan/repro-haskell-stack-multiproj. If you have any idea what difference between the two could be responsible, I'm all ears.

It's bed-time where I am now, but I'll keep looking into this to see if I can narrow it down.

[tomasaschan]

After doing some more digging on this, I've found that this seems to reproduce only if the latest attempts at building the project failed. After a successful build, it works again - and keeps working even if I break things.

I suspect the problem is that the project has to be in a building state when the language server starts; if not, it fails to start the REPL and doesn't retry. If I restart the HLS process (through the command palette) when the project is in a good state again, it starts working.

Thus, I don't think this is a Stack bug - but I don't know what the best fix would be, but I think it would be very helpful to at least displaying a message that says "The language server failed to initialize, because your project doesn't compile. Please fix the build errors and then restart the language server."

[fendor]

It still is a stack bug if the stack repl produces such an error message. It should still try to open a repl session.

[jneira]

@tomasaschan as mentioned in the last comment, although you observe the efect in the ide, the root cause is stack is not able to open a repl session. hls needs that session to show the errors in the editor.
So we should open an issue upstream in the stack repo.