-
-
Notifications
You must be signed in to change notification settings - Fork 366
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
Comments
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 |
I think this is also related to #735 (same root issues?) |
Yeah, thanks for linking the previous issue, not totally sure though |
Hi there, Adding a
seemed to fix the issue for me. |
I was linking it because I constantly get this "staleness" issue - if I add a new export to something in |
Nice to see you can workaround the issue, have you got the opportunity to check if removing |
Hi @jneira When I remove the When I reload developer window, that error is gone and the former error is reproduced: Readding the hie.yaml fixes the error again. |
Thanks for confirming it, @fendor does that behaviour make sense for you? |
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. |
Ok, it would be great to distinguish cases, to help trace the cause, so taking in account your last comment: with |
@jneira No, not really. Maybe the generated |
It is the simpler stack one: #1822 (comment) |
but it doesn't work without it, |
Okay so I've made a new project to try to provide as much information as possible: Initial steps:
After modifying Lib.hs, the following error is in Main.hs
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. |
This is an awesome bug report! Very detailed and great to follow. I will try to reproduce it locally as well. |
Can reproduce as described. Interesting finds:
Which is wrong, Compare to the logs with
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... |
The issue was reproduced by @dharmatech in #2058, log here: https://pastebin.com/hGtJMiC7, cabal file here: #2058 (comment) |
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... |
@santiweight absolutely agree with you, this bug makes hls almost unusable with stack |
I have a shortcut key for restart in my setup, and just press the key when I cross the section border. |
Thanks for the response. I have an explicit stack cradle outlined like this:
which doesn't work for me sadly. @Ailrun that's also my settle solution for the time being. |
I spent a couple of minutes on it again, and it honestly seems like a stack bug. E.g. when I change something in > 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. |
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 Unfortunately, the final verdict is, thus, |
@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. |
AFAIK it haven't, at least for HLS (not sure about HIE, but I doubt it was the case) |
@fendor Thanks again for the analysis. For completeness and to help move upstream the fix, we have two issues:
do we need to fix both things upstream to fix this issue or only the second one? |
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. |
Yeah we have already an issue about the former in hls: #318 linked with the upstream one: commercialhaskell/stack#4616 |
I think this is essentially #366, there we have the workarounds and linked upstream stack issues |
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. |
Hello, I am having trouble with erroneous error messages from the linter.
The steps I have taken are:
stack new <project-name>
stack setup
Below are screenshots of the error I see.
Whenever I use
stack run
, the program compiles and runs as expected.The text was updated successfully, but these errors were encountered: