Skip to content

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

Closed
Vic-M opened this issue Mar 5, 2023 · 5 comments · Fixed by #3686
Closed

Incorrect flags when loading multiple executable components on GHC 9.4 #3513

Vic-M opened this issue Mar 5, 2023 · 5 comments · Fixed by #3686
Labels
component: ghcide type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@Vic-M
Copy link

Vic-M commented Mar 5, 2023

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

  1. Open projectA/app/Main.hs
  2. Open projectB/app/Main.hs right after

Actual behaviour

HLS is unable to recognize libraries that are exclusively in projectB cabal's file.

Could not load module ‘Data.Aeson’
It is a member of the hidden package ‘aeson-2.1.2.1’.
Perhaps you need to add ‘aeson’ to the build-depends in your .cabal file.
It is a member of the hidden package ‘aeson-2.1.1.0’.
Perhaps you need to add ‘aeson’ to the build-depends in your .cabal file.
It is a member of the hidden package ‘aeson-2.1.1.0’.
Perhaps you need to add ‘aeson’ to the build-depends in your .cabal file.

image

Expected behaviour

HLS should be able to find installed libraries from all cabal files in the project.

@Vic-M Vic-M added status: needs triage type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels Mar 5, 2023
@fendor
Copy link
Collaborator

fendor commented Mar 5, 2023

Hi, thank you for your bug report!

I can reproduce on windows.
Maybe we use relative filepaths somewhere...

@georgefst
Copy link
Collaborator

georgefst commented May 11, 2023

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.)

@L0neGamer
Copy link

L0neGamer commented May 19, 2023

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 shakespeare-2.1.0, directory-1.3.7.1, and others.

Do the maintainers need any investigation on symptom-observers' behalf?

I compiled hls using ghcup compile hls -g 1.10.0.0 --ghc 9.4.5 --cabal-update, using 9.4.5 installed with ghcup.

@georgefst
Copy link
Collaborator

This stems from 6c99563, and commenting out the Set up a multi component session with the other units on GHC 9.4 CPP branch appears to fix the behaviour. I don't know whether it's worth opening a PR doing so for now, as it might have other undesirable effects. And maybe there's a mistake that's obvious to @wz1000, who wrote the code. I don't personally know the new home units API well enough to easily debug much further.

PS. thanks @fendor for pointing me in the right direction.

@georgefst georgefst changed the title HLS can't handle two executables, each with their own .cabal file Incorrect flags when loading multiple executable components on GHC 9.4 Jun 13, 2023
@georgefst
Copy link
Collaborator

(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)

wz1000 added a commit that referenced this issue Jul 5, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
wz1000 added a commit that referenced this issue Jul 5, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
wz1000 added a commit that referenced this issue Jul 13, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
wz1000 added a commit that referenced this issue Jul 21, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
wz1000 added a commit that referenced this issue Jul 26, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
wz1000 added a commit that referenced this issue Jul 26, 2023
…fused multi component sessions.

Solution: include the hash of the options in the unit id when the unit id is called "main".

Fixes #3513
@mergify mergify bot closed this as completed in #3686 Jul 26, 2023
mergify bot pushed a commit that referenced this issue Jul 26, 2023
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ghcide type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants