Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positive: Main.hs (executable) does not recognise function defined in Lib.hs (library) #1822

Open
mgpwilson opened this issue May 11, 2021 · 30 comments
Labels
build tool: stack can-workaround component: hie-bios status: blocked Not actionable, because blocked by upstream/GHC etc. type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@mgpwilson
Copy link

Hello, I am having trouble with erroneous error messages from the linter.

The steps I have taken are:

  1. Created a new Haskell Stack project with stack new <project-name>
  2. Used stack setup
  3. Created a function in Lib.hs and then used that function in Main.hs

Below are screenshots of the error I see.

image
image

Whenever I use stack run, the program compiles and runs as expected.

@jneira
Copy link
Member

jneira commented May 12, 2021

Hi, thanks for the bug report. Unfortunately the editor not always reflect changes on the fly, does the error persist after closing the editor, execute stack build in a console and reopening the editor?

@jneira jneira transferred this issue from haskell/vscode-haskell May 12, 2021
@jneira jneira added build tool: stack component: ghcide type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels May 12, 2021
@googleson78
Copy link
Contributor

googleson78 commented May 12, 2021

I think this is also related to #735 (same root issues?)

@jneira
Copy link
Member

jneira commented May 12, 2021

I think this is also related to #735 (same root issues?)

Yeah, thanks for linking the previous issue, not totally sure though

@jneira jneira changed the title Linter in Main.hs does not recognise function defined in Lib.hs False positive: Main.hs (executable) does not recognise function defined in Lib.hs (library) May 12, 2021
@mgpwilson
Copy link
Author

Hi there,

Adding a hie.yaml file with the contents

cradle:
  stack:

seemed to fix the issue for me.

@googleson78
Copy link
Contributor

I think this is also related to #735 (same root issues?)

Yeah, thanks for linking the previous issue, not totally sure though

I was linking it because I constantly get this "staleness" issue - if I add a new export to something in lib, hls won't detect in in another component, until I manually rebuild lib. And it seems related to me, because they're both related to intercomponent dependencies of some sort.

@jneira
Copy link
Member

jneira commented May 12, 2021

@mgpwilson

Hi there,

Adding a hie.yaml file with the contents

cradle:
  stack:

seemed to fix the issue for me.

Nice to see you can workaround the issue, have you got the opportunity to check if removing hie.yaml the issue is reproduced again?

@mgpwilson
Copy link
Author

mgpwilson commented May 12, 2021

Hi @jneira

When I remove the hie.yaml file I get the following error:

image

When I reload developer window, that error is gone and the former error is reproduced:

image

image

Readding the hie.yaml fixes the error again.

@jneira
Copy link
Member

jneira commented May 12, 2021

Thanks for confirming it, @fendor does that behaviour make sense for you?

@mgpwilson
Copy link
Author

Hi, thanks for the bug report. Unfortunately the editor not always reflect changes on the fly, does the error persist after closing the editor, execute stack build in a console and reopening the editor?

Sorry I didn't reply to this before. The error did not persist after following the steps you listed. Each time I reloaded the developer window, the linter would recognise changes that were present at reloading.

@jneira
Copy link
Member

jneira commented May 12, 2021

The error did not persist after following the steps you listed. Each time I reloaded the developer window, the linter would recognise changes that were present at reloading.

Ok, it would be great to distinguish cases, to help trace the cause, so taking in account your last comment: with hie.yaml you dont need to restart and execute stack build?

@fendor
Copy link
Collaborator

fendor commented May 12, 2021

@jneira No, not really. Maybe the generated hie.yaml file is interesting?

@jneira
Copy link
Member

jneira commented May 12, 2021

It is the simpler stack one: #1822 (comment)

@fendor
Copy link
Collaborator

fendor commented May 12, 2021

but it doesn't work without it, implicit-hie generates a more elaborated hie.yaml than that.

@mgpwilson
Copy link
Author

mgpwilson commented May 13, 2021

Okay so I've made a new project to try to provide as much information as possible:

Initial steps:

  1. Created new package with stack new ninety-nine-problems
  2. Opened code in folder ninety-nine-problems

After modifying Lib.hs, the following error is in Main.hs

image

  1. Ran stack setup. Above error persists
  2. Run stack build. Above error is gone!
  3. Define printSomething in Lib.hs and use it in the main function of Main.hs. The below error appears.

image

  1. Run stack run. Code compiles as expected. Error persists.
  2. Reload developer window. Error is gone!
  3. Define a new function printSomethingElse and use it in main. Variable not in scope error reappears.
  4. Reload developer window without running stack build. Error persists.
  5. Create hie.yaml with same contents as in False positive: Main.hs (executable) does not recognise function defined in Lib.hs (library) #1822 (comment). Error persists.
  6. Reload developer window. Error is gone.
  7. Define new function printSomethingElseElse in Lib.hs and use it in Main.hs. No error.

Apologies, I'm not too used to reporting bugs but I hope that provides some use. Let me know if there's anything else you specifically want me to test.

@fendor
Copy link
Collaborator

fendor commented May 13, 2021

This is an awesome bug report! Very detailed and great to follow. I will try to reproduce it locally as well.

@fendor
Copy link
Collaborator

fendor commented May 15, 2021

Can reproduce as described.

Interesting finds:
With the implicit-cradle, we see the following log:

Typechecking reverse dependencies for NormalizedFilePath "/home/hugin/Documents/haskell/ninety-nine/src/Lib.hs": Just []

Which is wrong, Main is one of the reverse dependencies.

Compare to the logs with hie.yaml:

Typechecking reverse dependencies for NormalizedFilePath "/home/hugin/Documents/haskell/ninety-nine/src/Lib.hs": Just [NormalizedFilePath "/home/hugin/Documents/haskell/ninety-nine/app/Main.hs"]

I blindly guess, this might be a bug in ghcide session loading.

At the moment, I cant reproduce the same issue with cabal. Which is very weird. If it is a bug in session loading, it should be affected, too...

@jneira
Copy link
Member

jneira commented Aug 2, 2021

The issue was reproduced by @dharmatech in #2058, log here: https://pastebin.com/hGtJMiC7, cabal file here: #2058 (comment)

@santiweight
Copy link
Collaborator

Heya, my intention is not to clog - I know all of you are busy and put great work into HLS.

I'll just give honest feedback that this issue makes HLS very very abrasive for most usages. Almost any project has some form of test->lib dependency, and having to reload the entire server when coding almost any small change is a pretty big inconvenience.

I think you all know this, but I just want to check in with my experience, given that this issue seems to have persisted for some 8ish months now (there is a similar but older issue that parallelsl this one). If you have anywhere to point me to, I would be happy to take a look and see if I can do some debugging. Alternatively, if this issue is for more seasoned HLS contributors (which I suspect is the case), then I would be happy to start a git "bounty" or buy someone 100 coffees to help speed things along :), or help someone however that help is wanted...

@jneira
Copy link
Member

jneira commented Aug 8, 2021

@santiweight absolutely agree with you, this bug makes hls almost unusable with stack
we found that adding a simple stack explicit cradle seemed to workaround the issue, does it for you too?
I would ask @Ailrun how he deals with this issue, as he is using stack iirc

@Ailrun
Copy link
Member

Ailrun commented Aug 8, 2021

I have a shortcut key for restart in my setup, and just press the key when I cross the section border.

@santiweight
Copy link
Collaborator

santiweight commented Aug 8, 2021

Thanks for the response. I have an explicit stack cradle outlined like this:

cradle:
   stack:
     - path: "./src"
       component: "poker-base:lib"
     - path: "./test"
       component: "poker-base:test:all-tests"

which doesn't work for me sadly.

@Ailrun that's also my settle solution for the time being.

@fendor
Copy link
Collaborator

fendor commented Aug 9, 2021

I spent a couple of minutes on it again, and it honestly seems like a stack bug.

E.g. when I change something in Lib.hs, then:

> stack repl ninety-nine-problems:exe:ninety-nine-problems-exe
Using main module: 1. Package `ninety-nine-problems' component ninety-nine-problems:exe:ninety-nine-problems-exe with main-is file: /home/baldr/Documents/haskell/ninety-nine-problems/app/Main.hs
ninety-nine-problems> configure (lib + exe)
Configuring ninety-nine-problems-0.1.0.0...
ninety-nine-problems> 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: ninety-nine-problems
GHCi, version 8.10.4: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/baldr/.ghci
[1 of 2] Compiling Main             ( /home/baldr/Documents/haskell/ninety-nine-problems/app/Main.hs, interpreted )

/home/baldr/Documents/haskell/ninety-nine-problems/app/Main.hs:6:8: error:
    • Variable not in scope: someFunc2 :: IO ()
    • Perhaps you meant ‘someFunc’ (imported from Lib)
  |
6 | main = someFunc2
  |        ^^^^^^^^^
Failed, no modules loaded.

<no location info>: error:
    Could not load module ‘Paths_ninety_nine_problems’
    it is a hidden module in the package ‘ninety-nine-problems-0.1.0.0’
Loaded GHCi configuration from /run/user/1000/haskell-stack-ghci/80188eea/ghci-script

Which should not have happened, it should have rebuilt the library component.

Admittedly, it should work when HLS opens the Library component, but one issue after another.

@fendor
Copy link
Collaborator

fendor commented Aug 9, 2021

Additionally, we see here

> hie-bios debug src/Lib.hs
...
GHC options:           -i -odir=/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/odir -hidir=/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/odir -hide-all-packages -i/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/dist/x86_64-linux-nix/Cabal-3.2.1.0/build -i/home/baldr/Documents/haskell/ninety-nine-problems/src -i/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/dist/x86_64-linux-nix/Cabal-3.2.1.0/build/autogen -i/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/dist/x86_64-linux-nix/Cabal-3.2.1.0/build/global-autogen -stubdir=/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/dist/x86_64-linux-nix/Cabal-3.2.1.0/build -I/nix/store/vkyg60kc8bzn089vjmadwwx0iaa4l440-ghc-8.10.4/include -I/nix/store/vygn2385bngrgfdagb3gds6bxfp5h4dc-git-2.31.1/include -I/nix/store/74kv08wjf06ifgk4dxrnra4qhzr5s1w4-gcc-wrapper-10.3.0/include -I/nix/store/wm9fdwbqvawsr5i66hp6kb9vfznapdn7-gmp-6.2.1-dev/include -L/nix/store/vkyg60kc8bzn089vjmadwwx0iaa4l440-ghc-8.10.4/lib -L/nix/store/vygn2385bngrgfdagb3gds6bxfp5h4dc-git-2.31.1/lib -L/nix/store/74kv08wjf06ifgk4dxrnra4qhzr5s1w4-gcc-wrapper-10.3.0/lib -L/nix/store/qkc31n1f1bs1l8m7k4fxyp4ykidy2cjr-gmp-6.2.1/lib -package-id=base-4.14.1.0 -optP-include -optP/home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/ghci/ebbf0c21/cabal_macros.h -ghci-script=/run/user/1000/haskell-stack-ghci/a6a94610/ghci-script -package-db /home/baldr/Documents/haskell/ninety-nine-problems/.stack-work/install/x86_64-linux-nix/0cddea7c3f96a91112b31619351e85e026cd5fa5d73c071232a9ca415db9ac3c/8.10.4/pkgdb -package-db /home/baldr/.stack/snapshots/x86_64-linux-nix/0cddea7c3f96a91112b31619351e85e026cd5fa5d73c071232a9ca415db9ac3c/8.10.4/pkgdb -package-db /nix/store/vkyg60kc8bzn089vjmadwwx0iaa4l440-ghc-8.10.4/lib/ghc-8.10.4/package.conf.d
...

Admittedly, a bit much, but the important bit is that we have no flag such as -this-unit-id. Thus, HLS can not know what the component is named, and consequentially HLS can not handle the library component dependency of the executable. Therefore, reloading fails, as HLS is not aware of the local dependency.

Unfortunately, the final verdict is, thus, cant fix here, we need to patch stack.

@Ailrun Ailrun added status: blocked Not actionable, because blocked by upstream/GHC etc. and removed status: needs attention component: ghcide labels Aug 9, 2021
@jneira
Copy link
Member

jneira commented Aug 9, 2021

@fendor thanks a lot to take a look, your wisdom was needed here 🙂

A ticket in the stack issue tracker would be really nice (a new or existing one) to continue make progress on this.
Otoh, this has been a regression?, did it work in hls at some point?

@Ailrun
Copy link
Member

Ailrun commented Aug 9, 2021

AFAIK it haven't, at least for HLS (not sure about HIE, but I doubt it was the case)

@jneira
Copy link
Member

jneira commented Aug 9, 2021

Unfortunately, the final verdict is, thus, cant fix here, we need to patch stack.

@fendor Thanks again for the analysis. For completeness and to help move upstream the fix, we have two issues:

  • stack repl exec-comp does not rebuild the lib component if it has changed. This one is easy to reproduce and has a clear manifestation in a direct use of stack itself
  • stack does not pass --this-unit-id when doing a stack repl (or never?) and hls cant use it to identify the library component (theoretically there could be several ibs in a package). Not sure if that is observable in a direct use of stack.

do we need to fix both things upstream to fix this issue or only the second one?

@fendor
Copy link
Collaborator

fendor commented Aug 10, 2021

I think I remember seeing an issue for the former already... but don't have it at hand.

Well, both are required for a smooth experience, otherwise you would run into an error when you only open the executable which gets fixed once you open the library component.
Ideally, we fix both, and s-b-i will be helpful here as well

@jneira
Copy link
Member

jneira commented Aug 10, 2021

Yeah we have already an issue about the former in hls: #318 linked with the upstream one: commercialhaskell/stack#4616
So we have to open or find another one about the --this-unit-id thing. Not sure how to fill it tbh.

@jneira
Copy link
Member

jneira commented Jan 31, 2022

I think this is essentially #366, there we have the workarounds and linked upstream stack issues

@jneira jneira closed this as completed Jan 31, 2022
@fendor
Copy link
Collaborator

fendor commented Jul 26, 2022

I re-open this, since I don't feel like these issues are truly the same, they seem to have different root causes and present themselves differently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build tool: stack can-workaround component: hie-bios status: blocked Not actionable, because blocked by upstream/GHC etc. type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

No branches or pull requests

6 participants