ghcide stuck on a failed hie.yaml with no feedback

[teto]

I have this faulty hie.yaml (as in .OUT/generated.flags didn't exist)

cradle:
  bios:
    shell: cat ".OUT/generated.flags" > $HIE_BIOS_OUTPUT

and I had ghcide 0.4.0 stuck on

Step 1/4: Finding files to test in /home/teto/nova/project

Hopefully hie-bios debug showed the error.

at some point I also had symlink cycles in my folders and IIRC I had ghcide endlessly looking for files without much to guess why (even with --verbose).

[fendor]

I think, the former is a hie-bios bug (although can be handled in ghcide if the interface is insufficient), while the latter is a ghcide bug.
If the bios program is faulty, it should not crash the whole application without feedback.

Also, regarding the second issue, my bet is that expandFiles is at fault here.
EDIT: yep, that function follows symlinks and if they form a cycle, there is an endless recursion.

[teto]

I wanted to iterate on the point 2 of this message haskell/hie-bios#250 (comment) .
The matter is not that its a symlink in this case but that ghcide is scanning the whole file hierarchy in ./. even though my multicradle config (the same as in that message), just mentions subfolders of project/ while setting ./. to the none cradle. I leave ghcide (in fact the haskell-language-server) scans those big bazel folders but in the end it crashes or is killed by the system, I am not sure which.

One workaround I found is to call haskell-language-server --cwd project but I wonder if it can find the hie.yaml in a parent folder of project ?

EDIT one answer from @fendor on IRC

hls and ghcide do not honour the hie.yaml when finding haskell source files for testing

NB: I checked the system log and hls is killed by the oom-killer so no crash.

[jneira]

@teto are you still experienced the issue with newer versions of hls?

[teto]

I've improved my hie.yaml alot since then, I dont see the issue anymore.