-
-
Notifications
You must be signed in to change notification settings - Fork 390
Incorrect flags when loading multiple executable components on GHC 9.4 #3513
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
Comments
Hi, thank you for your bug report! I can reproduce on windows. |
I've just hit this immediately after upgrading from GHC 9.2.7 to 9.4.5. (Well, that bump was actually in a Haskell.Nix project, which simultaneously upgraded HLS to the commit cda1325 for various reasons, having I think previously been using the 1.10.0.0 release. But I also see this error when using 1.10.0.0 on GHC 9.4.4, without Nix, so it seems likely that GHC 9.4, or its handling within HLS, is the culprit. But I can investigate further if it would be helpful.) |
My company upgraded to GHC 9.4.5 last thursday and we're getting similar issues with our HLS instances. We have multiple packages in the same project, and the ones marked as missing include both our own packages and ones like Do the maintainers need any investigation on symptom-observers' behalf? I compiled hls using |
This stems from 6c99563, and commenting out the PS. thanks @fendor for pointing me in the right direction. |
(changing the title because I've been consistently seeing this with https://github.com/georgefst/evdev, in which the executables are defined in the same cabal file, and because it's now clear this is 9.4-specific) |
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
…fused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513
* Only bring units actually depended on into scope on 9.4+ * Cabal uses `main` as the unit id of all executable packages. This confused multi component sessions. Solution: include the hash of the options in the unit id when the unit id is called "main". Fixes #3513 * Fix call hierarchy tests
Hello, I'm not sure if this is a configuration issue with my hie.yaml, but I'm unable to get HLS to work with two Main.hs files at the same time. There's no issues with compiling both of them with cabal though.
Your environment
Which OS do you use?
Windows WSL2 running CentOS Stream 9
Which version of GHC do you use and how did you install it?
GHC 9.4.4 from ghcup
How is your project built (alternative: link to the project)?
https://gitlab.com/vmatassa/hls-two-main-example
Which LSP client (editor/plugin) do you use?
vscode
Which version of HLS do you use and how did you install it?
HLS 1.9.1.0 from ghcup
Steps to reproduce
Actual behaviour
HLS is unable to recognize libraries that are exclusively in projectB cabal's file.
Expected behaviour
HLS should be able to find installed libraries from all cabal files in the project.
The text was updated successfully, but these errors were encountered: