Haskell-language-server: CodeLens tries to rename module name to match the filename when the file is listed in the "main-is" section of the cabal file

[poscat0x04]

The module name of the file that "main-is" is pointing to should always be Main.

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 0.6.0.0 (GHC: 8.10.2) (PATH: /nix/store/aa763nk6yn1hdjqcwj9l7slkfl52i61d-haskell-language-server-0.6.0.0/bin/haskell-language-server-wrapper)
Tool versions found on the $PATH
cabal:      3.2.0.0
stack:      Not found
ghc:        8.10.2

VSCode

[konn]

I think this issue is already fixed in #616, which will be included in upcoming monthly release.

[poscat0x04]

Hmmm, I don't think #616 will fix this. For example, hls will still try to rename the module name of "test/Spec.hs" from Main to Spec after the fix.

[konn]

Hmmm, I don't think #616 will fix this. For example, hls will still try to rename the module name of "test/Spec.hs" from Main to Spec after the fix.

Ah, you're right! So PR #616 solved this issue only partially and we need to use more metadata to determine the module name.

[tittoassini]

The plugin provides just a suggestion, it doesn't force you to do anything.

Naturally, it would be nice to solve the issue, but where would the necessary metadata come from?

[konn]

Naturally, it would be nice to solve the issue, but where would the necessary metadata come from?

Hmm, it seems that flags given by hie-bios don't include any information about main-is.
Since HLS is build-system agnostic, IIUC, I think it is not so easy to do with GHC API alone...

[poscat0x04]

By parsing the cabal file? I feel like hie-bios is responsible for this. Unfortunately, I'm not really familiar with how HLS works under the hood so I can't answer that question.

[berberman]

IIUC, currently the shake system does not store component details like main-is. hie-bios does not consider the PackageDescription; instead, implicit-hie will parse cabal files to get component root, options, etc., which ghcide uses to initialize IDE session. Actually, we don't care about if the component is a library, or a test, or even a benchmark.

[jneira]

Parsing the cabal file could be the way to go, and it would be already in scope if we recover the hie package plugin #155. But it is not the case for now.
We could ask hie-bios for more info, but not sure if it would be feasible until it uses the new cabal show-build-info feature. What do you think @fendor?