Ghcide: Cradle for autogenerated Paths_* files

[googleson78]

I'm not sure if this is the right place for this issue, so sorry in advance if it isn't!

When using the autogenerated Paths_ module with an explicit cradle ghcide understandably complains that the .stack-work/blablabla/autogen/Paths_<project>.hs file matches no prefix in the cradle.

For now I just hardcoded the path to the Paths_<project>.hs file in my hie.yaml and gave it some arbitrary component to load (<project>:lib), but I don't think this is intended or great UX (as it is an artifact of compilation - it contains build directories internal to stack/cabal in its path)

[mpickering]

This is a bug in stack not listing the Paths_ module in the targets for the component.

[googleson78]

Do you know of a way to get the targets for a given component, so I can file a proper bug report to stack?

[Avi-D-coder]

For implicit-hie I remove modules found in autogen-modules from other-modules.

In light of this that seems like the wrong behavior?

[jneira]

Maybe a relatively simple workaround could be

path: .stack-work/
component: myproject:lib

In the hope all generated modules under .stack-work will be loaded by that component.
I have to test it, though.

Confirmed a hie.yaml like this:

cradle:
  stack:
    - path: "./.stack-work"
      component: "stack-test:lib"
    - path: "./app"
      component: "stack-test:exe:stack-test"
    - path: "./src"
      component: "stack-test:lib"
    - path: "./test"
      component: "stack-test:test:stack-test-test"

do the workaround

[Sir4ur0n]

Maybe a dumb question: why not use a multi-cradle + the none cradle for ./.stack-work directory? AFAIU you associate .stack-work with the lib component, but is that necessary?

[jneira]

The cradle should be able to load the Paths_project.hs module cause it could be used in regular modules. As it does not have any dependencies, it could be loaded with a plain call to ghc (not tested) but the lib component can handle too. Not sure if the direct cradle, which only uses ghc is supported by hls/ghcide.

[googleson78]

This can now be closed due to https://github.com/haskell/ghcide/issues/819, right?

[jneira]

Yeah, for completeness:

• the described workaround is not longer needed for cabal (just tested it) and it does not work for stack with lastest hls/ghcide
• once a new stack version is released hls will be able to handle those modules directly for stack too

[googleson78]

Happily, a release candidate for stack (2.5) just popped up with the patch!