Ghcide: Auto-generated Paths_xxx is a "member of the hidden package xxx" with stack cradle

[uncle-betty]

I've recently graduated from navigating Haskell code via grep to fast-tags to ghcide. What a change! Thank you for making our lives easier.

Here's a minimal working example of a stack-based library project that leads to an error, and I'm not sure whether it's me or ghcide. It seems like there's a problem with the auto-generated Paths_Repro.hs file of my project.

File:     /home/tlo/repro/src/Repro.hs
Hidden:   no
Range:    3:7-3:18
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Paths_Repro’
  It is a member of the hidden package ‘Repro-0.0.0’.
  You can run ‘:set -package Repro’ to expose it.
  (Note: this unloads all the modules in the current scope.)

I am using the following environment based on GHC 8.8.4.

tlo@carol:~/repro$ stack --version
Version 2.3.3, Git revision cb44d51bed48b723a5deb08c3348c0b3ccfc437e x86_64 hpack-0.33.0
tlo@carol:~/repro$ stack exec -- hie-bios version
hie-bios version 0.7.1 compiled by GHC 8.8.4
tlo@carol:~/repro$ stack exec -- ghcide --version
ghcide version: 0.4.0 (GHC: 8.8) (PATH: /home/tlo/.local/bin/ghcide) (GIT hash: 153536bda11fbf1ebee8434aa981911db73d09b8)

The above hie-bios executable was built together with ghcide (stack install --stack-yaml stack88.yaml hie-bios).

This is my directory layout in ~/repro. data and src are directories.

tlo@carol:~/repro$ tree
.
├── data
├── hie.yaml
├── Repro.cabal
├── Setup.hs
├── src
│   └── Repro.hs
└── stack.yaml

2 directories, 5 files

The .cabal file contains just a library. Note the data directory, which will lead to auto-generation of Paths_Repro.hs. I'm including it as an exposed module.

tlo@carol:~/repro$ cat Repro.cabal 
cabal-version:     3.0
name:              Repro
version:           0.0.0

data-dir:          data

library
  default-language: Haskell2010
  hs-source-dirs:   src
  exposed-modules:  Repro, Paths_Repro
  build-depends:    base >= 4.9.0.0

The source code of the library is pretty simple - all it does is import the auto-generated Paths_Repro.hs.

tlo@carol:~/repro$ cat src/Repro.hs 
module Repro where

import Paths_Repro

hie.yaml makes the library source code as well as the auto-generated Paths_Repro.hs part of the Repro:lib component.

tlo@carol:~/repro$ cat hie.yaml 
cradle:
  stack:
    - path: 'src'
      component: 'Repro:lib'
    - path: '.stack-work/dist'
      component: 'Repro:lib'

stack.yaml is pretty minimal and points to the current directory.

tlo@carol:~/repro$ cat stack.yaml 
resolver: lts-16.12
compiler: ghc-8.8.4
compiler-check: match-exact

packages:
  - "."

Setup.hs is pretty minimal, too.

tlo@carol:~/repro$ cat Setup.hs 
import Distribution.Simple
main = defaultMain

Let's build. So far, so good.

tlo@carol:~/repro$ stack build
Repro> configure (lib)
Configuring Repro-0.0.0...
Repro> build (lib)
Preprocessing library for Repro-0.0.0..
Building library for Repro-0.0.0..
[1 of 2] Compiling Paths_Repro
[2 of 2] Compiling Repro
Repro> copy/register
Installing library in /home/tlo/repro/.stack-work/install/x86_64-linux/eca3ea2dfcf47802c16cbff074593024128a25b42227008f01d8d58674357ac1/8.8.4/lib/x86_64-linux-ghc-8.8.4/Repro-0.0.0-KYMSFfd0OHq96ZnTxqxItm
Registering library for Repro-0.0.0..

Let's run ghcide. I'm only running it on src to avoid the No prefixes matched error when ghcide skips over Setup.hs. Without src, the error message about Paths_Repro.hs is the same, though.

tlo@carol:~/repro$ stack exec -- ghcide src
ghcide version: 0.4.0 (GHC: 8.8) (PATH: /home/tlo/.local/bin/ghcide) (GIT hash: 153536bda11fbf1ebee8434aa981911db73d09b8)
Ghcide setup tester in /home/tlo/repro.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/4: Finding files to test in /home/tlo/repro
Found 1 files

Step 2/4: Looking for hie.yaml files that control setup
Found 1 cradle
  (/home/tlo/repro/hie.yaml)

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "src/Repro.hs"
Output from setting up the cradle Cradle {cradleRootDir = "/home/tlo/repro", cradleOptsProg = CradleAction: Stack}
> Configuring GHCi with the following packages: Repro
> /home/tlo/repro/.stack-work/install/x86_64-linux/eca3ea2dfcf47802c16cbff074593024128a25b42227008f01d8d58674357ac1/8.8.4/pkgdb:/home/tlo/.stack/snapshots/x86_64-linux/eca3ea2dfcf47802c16cbff074593024128a25b42227008f01d8d58674357ac1/8.8.4/pkgdb:/home/tlo/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/package.conf.d
[INFO] Using interface files cache dir: /home/tlo/.cache/ghcide/main-1fe712b57e70d0bcc9e2401739aeaa38de845e35
[INFO] Making new HscEnv[main]
File:     /home/tlo/repro/src/Repro.hs
Hidden:   no
Range:    3:7-3:18
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Paths_Repro’
  It is a member of the hidden package ‘Repro-0.0.0’.
  You can run ‘:set -package Repro’ to expose it.
  (Note: this unloads all the modules in the current scope.)
Files that failed:
 * /home/tlo/repro/src/Repro.hs

Completed (0 files worked, 1 file failed)

I don't think that this is right. But maybe I'm misunderstanding things. I would have thought that both, Repro as well as Paths_Repro are a part of the Repro-0.0.0 package. At least that's what I thought my hie.yaml file said. How would hidden packages factor into this?

Checking with hie-bios succeeds (with what I think is an unrelated warning).

tlo@carol:~/repro$ stack exec -- hie-bios check src/Repro.hs 
src/Repro.hs:3:1:Warning: The import of ‘Paths_Repro’ is redundant
  except perhaps to import instances from ‘Paths_Repro’
To import instances alone, use: import Paths_Repro()

When I change Repro.cabal to make Paths_Repro an "other" module, then this changes the error message.

tlo@carol:~/repro$ cat Repro.cabal
[...]
  exposed-modules:  Repro
  other-modules:    Paths_Repro
[...]
tlo@carol:~/repro$ stack exec -- ghcide src
ghcide version: 0.4.0 (GHC: 8.8) (PATH: /home/tlo/.local/bin/ghcide) (GIT hash: 153536bda11fbf1ebee8434aa981911db73d09b8)
[...]
File:     /home/tlo/repro/src/Repro.hs
Hidden:   no
Range:    3:7-3:18
Source:   not found
Severity: DsError
Message:  Could not load module ‘Paths_Repro’it is a hidden module in the package ‘Repro-0.0.0’
Files that failed:
 * /home/tlo/repro/src/Repro.hs

Completed (0 files worked, 1 file failed)

It almost looks like ghcide considers Repro.hs and Paths_Repro.hs to live in different packages, no?

In any case, I'm now wondering whether I am missing something, or whether there's an issue with ghcide.

[uncle-betty]

Oh, and for reference: I got the idea to add .stack-work/dist to hie.yaml from #574.

[uncle-betty]

Looks like 5dd52ec introduced the issue about two weeks ago. Versions before that correctly process my example. Isn't git bisect magic?

[ndmitchell]

CC @pepeiborra - that doesn't look like it would have been an expected fallout.

[pepeiborra]

I think this is a cradle problem, unrelated to 5dd52ec. But I might be wrong.

A cabal cradle does the right thing. The cradle generated by gen-hie does it right as well. But the stack cradle wrongly doesn't list the Paths module, and that prevents ghcide from locating them, which leads to the unhelpful error message "this module lives in a package".

Stack cradle

pepeiborra@pepeiborra-mbp ~/s/init [1]> hie-bios flags src/Main.hs
Options: ["-i","-odir=/Users/pepeiborra/scratch/init/.stack-work/odir","-hidir=/Users/pepeiborra/scratch/init/.stack-work/odir","-hide-all-packages","-i/Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build/init","-i/Users/pepeiborra/scratch/init/src","-i/Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build/init/autogen","-i/Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build/global-autogen","-i/Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build/init/init-tmp","-stubdir=/Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build","-I/nix/store/88242sfskrw2mxv2pr4608nwccpw5q41-ghc-8.8.4/include","-I/nix/store/wrjgy3xkjsv7aqlmhhp1977ywmhk6l3q-git-2.28.0/include","-I/nix/store/kqpzwgfw1yw99536haqzg0jsa2lzxmqf-gcc-wrapper-9.3.0/include","-I/nix/store/m5wdi6x3ly0g6l0mibjnin82rbxjyasi-gmp-6.2.0-dev/include","-L/nix/store/88242sfskrw2mxv2pr4608nwccpw5q41-ghc-8.8.4/lib","-L/nix/store/wrjgy3xkjsv7aqlmhhp1977ywmhk6l3q-git-2.28.0/lib","-L/nix/store/kqpzwgfw1yw99536haqzg0jsa2lzxmqf-gcc-wrapper-9.3.0/lib","-L/nix/store/p20ys2ryai7h3hm2bihbk137is598k9z-gmp-6.2.0/lib","-package-id=base-4.13.0.0","-optP-include","-optP/Users/pepeiborra/scratch/init/.stack-work/ghci/e6487cf6/cabal_macros.h","-ghci-script=/private/var/folders/4m/d38fhm3936x_gy_9883zbq8h0000gn/T/haskell-stack-ghci/35ba5839/ghci-script","-package-db","/Users/pepeiborra/scratch/init/.stack-work/install/x86_64-osx-nix/4373fa4dbae3421908cbd892d447bf0f10a051cba390b6fe5bab7f602d67ca08/8.8.4/pkgdb","-package-db","/Users/pepeiborra/.stack/snapshots/x86_64-osx-nix/4373fa4dbae3421908cbd892d447bf0f10a051cba390b6fe5bab7f602d67ca08/8.8.4/pkgdb","-package-db","/nix/store/88242sfskrw2mxv2pr4608nwccpw5q41-ghc-8.8.4/lib/ghc-8.8.4/package.conf.d"]
ComponentDir: /Users/pepeiborra/scratch/init
Dependencies: ["init.cabal","package.yaml","stack.yaml"]

Cabal cradle

pepeiborra@pepeiborra-mbp ~/s/init> hie-bios flags src/Main.hs
Options: ["-fbuilding-cabal-package","-O0","-outputdir","/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-odir","/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-hidir","/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-stubdir","/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-i","-i/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-isrc","-i/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/autogen","-i/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/global-autogen","-I/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/autogen","-I/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/global-autogen","-I/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/init-tmp","-optP-include","-optP/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/build/init/autogen/cabal_macros.h","-hide-all-packages","-Wmissing-home-modules","-no-user-package-db","-package-db","/Users/pepeiborra/.cabal/store/ghc-8.8.4/package.db","-package-db","/Users/pepeiborra/scratch/init/dist-newstyle/packagedb/ghc-8.8.4","-package-db","/Users/pepeiborra/scratch/init/dist-newstyle/build/x86_64-osx/ghc-8.8.4/init-0.1.0.0/x/init/package.conf.inplace","-package-id","base-4.13.0.0","-XHaskell2010","src/Main.hs","Paths_init","-hide-all-packages"]
ComponentDir: /Users/pepeiborra/scratch/init
Dependencies: ["init.cabal","cabal.project","cabal.project.local"]

[pepeiborra]

(the implicit cradle gets it wrong too, /cc @jneira )

  Multi Cradle: No prefixes matched
  pwd: /Users/pepeiborra/scratch/init
  filepath:
  /Users/pepeiborra/scratch/init/.stack-work/dist/x86_64-osx-nix/Cabal-3.0.1.0/build/init/autogen/Paths_init.hs
  prefixes:
  ("./src/Main.hs",Stack {component = Just "init:exe:init", stackYaml = Nothing})
  ("./src/Paths_init.hs",Stack {component = Just "init:exe:init", stackYaml = Nothing})

[uncle-betty]

Thanks for looking into this!

Let me know, if I can help and run more experiments on my end to establish whether this is or isn't related to 5dd52ec.

So far I have "1 file worked" for the preceding commit, 2eb2689.

tlo@carol:~/repro$ stack exec -- ghcide src
ghcide version: 0.3.0 (GHC: 8.8) (PATH: /home/tlo/.local/bin/ghcide) (GIT hash: 2eb26896ae2bf0f33abd74ed76caac3c62c3d51d)
[...]
Completed (1 file worked, 0 files failed)
[INFO] finish: User TypeCheck (took 0.17s)

And I have "1 file failed" for 5dd52ec when running ghcide on the same directory as above.

tlo@carol:~/repro$ stack exec -- ghcide src
ghcide version: 0.3.0 (GHC: 8.8) (PATH: /home/tlo/.local/bin/ghcide) (GIT hash: 5dd52ec0ff35c9617c11cbeb2614584c9ba5f596)
[...]
Files that failed:
 * /home/tlo/repro/src/Repro.hs

Completed (0 files worked, 1 file failed)

Hence my earlier comment about 5dd52ec. Sorry, if this turns out to be a red herring.

[jneira]

@uncle-betty thanks for the detailed and polished bug report
For the shake of completeness, what is the effect in the editor? Do you get the same error opening Repro.hs within it and you dont get diagnostics or hover info in the module?

[jneira]

(the implicit cradle gets it wrong too, /cc @jneira )

The implicit cradle removes all autogen-modules from the cradle, and to be fair i dont know if it can do much more about that in a reliable way.
It could add them for the default lib/exe to mimic the hack described in #574. But it seems the hack does not work anymore, even with an explicit hie.yaml (due to 5dd52ec? the fact is the hack worked for me with an explicit stack hie.yamlat that point).

But if you dont add it in autogen-modules only would left the ugly hack of handle the module named Path_${package_name} if present in the .cabal file.

Not sure if adding those hacks it is a good idea, @Avi-D-coder?

[Avi-D-coder]

I was never really clear what to do about auto modules. Until an explicit hie.yaml works for this use case, it's a hie-bios issue.

I suspect hie-bios will need first class support for auto modules or for the build configs that use them.

[uncle-betty]

@jneira - I'm using vim with the vim-lsp plugin. When I put on the cursor on Paths_Repro in the import Paths_Repro directive in Repro.hs, then:

• :LspDefinition says No definition found
• :LspHover says No hover information found

Thanks again, everyone, for looking into this.

[uncle-betty]

I think I have some more insights.

It seems that 5dd52ec breaks my test case in a different way than current master. To locally resolve an import (= resolve it via a .hs file from the current project) back in 5dd52ec, it was enough for a .hs file for the imported module to exist in one of a number of expected directories. In contrast to this, with current master the bar is higher and my issue seems to be caused in the following, different way:

• Paths_Repro isn't reported as a target by hie-bios.
• For an import to be locally resolved, ghcide still needs to find a corresponding .hs file in one of the expected directories, but on top of that the imported module also needs to have been reported as a target. (See getTargetExists in the rule for GetLocatedImports.) As Paths_Repro isn't a target, things break.

So, where do the targets come from that hie-bios reports? hie-bios harvests the command line arguments passed to ghc for stack repl. These are the options that ghcide obtains by running the cradle via hie-bios. Later ghcide runs addCmdOpts on these options to derive targets from them. To that end, addCmdOpts considers any ghci script from among the command line arguments and scans it for :add directives. The modules discovered in this way are added to the targets returned by addCmdOpts.

It seems like the REPL's ghci script is created by stack. In my case, it only ontains Repro. So, only Repro is discovered and reported as a target.

Once I realized this, I looked for a workaround. I found that stack seems to put all modules found in hs-source-dirs into the REPL's ghci script. Thus, adding the directory that holds Paths_Repro to Repro.cabal would be a (super hacky) workaround. And, indeed, the following works. (Note the added hs-source-dirs.)

cabal-version:     3.0
name:              Repro
version:           0.0.0

data-dir:          data

library
  default-language: Haskell2010
  hs-source-dirs:   src
  hs-source-dirs:   .stack-work/dist/x86_64-linux/Cabal-3.2.0.0/build/autogen
  exposed-modules:  Repro, Paths_Repro
  build-depends:    base >= 4.9.0.0

So, what's the conclusion? I think that it depends on what "target" means.

• If the targets are supposed to exhaustively cover all source code files of a project, then I would say that hie-bios is broken. Possibly, it shouldn't just go through the REPL's ghci script, but maybe it should run :show modules in the REPL and parse the resulting output, which would include Paths_Repro.

• If the targets are merely to be considered "roots" from which to explore the dependency graph, then maybe ghcide's criterion for local import resolution (i.e., in order to be resolved locally, an import needs to be a target) is a tad too strict.

But then again, I guess that there's a reason why ghcide switched to the stricter criterion. Could someone shed some light on this decision? Based on this, I'd then go and open an issue for hie-bios and suggest something along the lines of :show modules.

[pepeiborra]

The contract between ghcide and hie-bios is that the latter provides a fully exhaustive list of ~cradles~ targets. This assumption is used at various places and is fundamental for correctness. @fendor correct me if I’m wrong.

The ghcide changes to locate modules started in https://github.com/haskell/ghcide/commit/b4589aebe639c9e5368e7b8413f794353aa55a55 which is a few commits earlier than the one you are pointing at. There are further changes later on spread across two or three PRs. These changes are required to prevent subtle bugs in multi package projects with shared import dirs.

Are you able to use the Cabal cradle while the issue gets looked at by the hie-bios team? That one works as expected.

[uncle-betty]

Oh, no rush. I am happy to use the workaround I discovered.

I didn't mean to come off as pushy. Apologies, if I did. I just had some time on my hands today to poke around and learn a little more about the inner workings of ghcide and hie-bios.

Thanks for the information on the guarantees given by hie-bios - and have a good weekend!

[fendor]

@pepeiborra Indeed, that is the contract, but Stack's interface is incomplete. Afaict, there is no way to obtain all Targets with stack. Unforunately, I don't think there is even an issue for it, yet.

@uncle-betty Awesome detective work, that is exactly what is happening.
The conclusion is in my opinion that stack needs to define the interface we need so that we can support it properly. As a first step, list the Paths_* module as a target in the ghci-script.

[ndmitchell]

@fendor do we have an upstream Stack ticket saying exactly what information we are missing? And the consequences for Stack users?

[jneira]

I am afraid that maybe there is no direct negative consequences for stack final users, so there won't be much motivation to fix it.
Therefore maybe we should think in a workaround in hie-bios or in implicit-cradle. Afaik hie-bios does not even fires the repl, only collects the flags that cabal would use to fire it so it could not call any repl command.
Maybe hie-bioscould add auto Paths_pack_name to the stack target. It is a pretty stable convention.

[ndmitchell]

I am afraid that maybe there is no direct negative consequences for stack final users, so there won't be much motivation to fix it.

Isn't the consequence for stack users a degraded HLS experience? That seems like a negative consequence.

Maybe hie-bioscould add auto Paths_pack_name to the stack target. It is a pretty stable convention.

That does seem a good idea though.

[fendor]

do we have an upstream Stack ticket saying exactly what information we are missing? And the consequences for Stack users?

No, I think we did not open one yet :/ Ghcide mitigated the issue by discovering modules by itself.

Maybe hie-bios could add auto Paths_pack_name to the stack target. It is a pretty stable convention.

Seems like a good work-around. Not sure though, how we can obtain the package_name :/

[uncle-betty]

I looked into modifying stack and the following is what I could come up with. It's a pretty small change. Maybe polish it a little (I can read Haskell but I can barely write it) and submit it as a proposal when opening a ticket with the stack team? It's a branch off current master.

https://github.com/uncle-betty/stack/compare/master...uncle-betty:hie-bios

Here's how stack determines the modules to be included in the ghci script:

• stack collects the modules from the .cabal file.
• It then tries to match up the modules with .hs files. However, it only considers source code directories specified in the .cabal file (hs-source-dirs).
• Those modules that have a matching .hs file go into the ghci script, the others don't. In particular, the auto-generated .hs files aren't found and thus don't go into the ghci script.

That's why explicitly adding the autogen directory as a source code directory to the .cabal file is a viable workaround.

My proposed changes make stack also check the autogen directories for .hs files, on top of the source code directories. It's basically about passing down the Cabal version to the point where it's needed to generate the autogen directory paths.

I have only superficial knowledge of the stack codebase, but at least I don't seem to have broken any tests in the stack test suite. So, maybe this is actually a viable fix.

[uncle-betty]

Here's a proposal for a plan B: a workaround in hie-bios.

https://github.com/uncle-betty/hie-bios/compare/master...uncle-betty:stack-autogen

This proposal extends the wrapper script by adding the following:

• It actually runs GHCi.
• It sets the GHCi prompt to __MARK__ framed by two newline characters, so that it always appears on a line by itself.
• It issues :show modules.
• The easily identifiable __MARK__ prompt allows it to extract the output of :show modules from the overall output generated by the GHCi session: it's the lines between the first and the second __MARK__ line. That's what the awk script extracts.
• It greps for modules whose names start with Paths_.
• It appends the resulting module names to the command line arguments (as opposed to the GHCi script). This works, because addCmdOpts doesn't only look for modules in GHCi scripts, it also looks for anything among the arguments that doesn't look like an actual option and returns it as a target.

This proposal also fixes the issue for me. As far as I can tell, two more things would be required to make this an actually viable solution for everyone:

• I assume that cabal.hs is for... Windows users? This would have to be extended, too.
• For Cabal-based builds, there probably is duplication now: Paths_Repro is found in the GHCi script as well as among the command line arguments. So there would have to be deduplication of the targets returned by addCmdOpts, I guess.

In any case, I was just curious to find out what it would take to implement a workaround. I still would prefer the change to stack. Just seems less hacky.

Do you guys have existing relations with the stack people or should I simply go ahead and open a ticket with them, describing the situation and the proposed tweak to stack, and link back to this issue?

[ndmitchell]

Does actually running ghci massively slow down loading up a package? That's my biggest concern - the time to start up a cradle is one of the annoying "does my project work" moments, so extending it is bad.

[uncle-betty]

Oooooh, performance. I should have tried this with something other than my toy example, right?

Turns out that the performance is... hilariously bad! I just fired up ghcide with the modified hie-bios and ran it on the Agda code base - and it takes about 90 seconds for each GHCi run. Nine zero seconds! And there are a lot of GHCi runs involved. Then I went out to get myself a tantuni dinner around the corner, returned home, and it's still running.

Well, then, I guess this one didn't fly. Hooray for plan As (plans A?) instead!

[jneira]

@uncle-betty really great work
If there is no good enough codificable workaround and there is a manual one (although an ungly one) i would go for the right one: patch stack.

[uncle-betty]

Thanks for your kind words. I am glad that I could contribute.

I opened a ticket with stack: https://github.com/commercialhaskell/stack/issues/5392

[uncle-betty]

Alright, the above plan A proposal was accepted and has been merged into the master branch of stack.

Things now work well for me with my toy example as well as the Agda source code. Woohoo! I am a happy camper.

I can't imagine that the change will be part of the upcoming version 2.3.4 of stack, but judging from the version used on master it should be no later than stack version 2.4.0.

For everyone who comes here via a search engine before stack 2.4.0 is released: a workaround is to add to the .cabal file a hs-source-dirs directive for the directory that holds auto-generated files. In the case of my toy example above, this would be .stack-work/dist/x86_64-linux/Cabal-3.2.0.0/build/autogen. See the discussion above for more details.

Thanks, everyone, for the discussion. This is a great outcome, I think. I'm closing this now.

[jneira]

If you dont mind, i will reopen this to give it more visibility, until the new stack version wih the fix is released
(i am afraid that it is an issue that can be related with the changes made in the patch 😟 )

[uncle-betty]

Thanks for the heads-up. I commented on the stack issue, contemplating a possible way forward.

[uncle-betty]

Just a quick update: stack version 2.5.1 was just released, which contains the fix proposed above to support auto-generated modules.

The stack error reported in commercialhaskell/stack#5407 was resolved by turning the error into a warning. So, the functionality required by ghcide is still there in the official stack release.

I guess now it's official - this is resolved! Woohoo!

Closing.