HLS often cannot find a `.hi.core` file in `~/.cache/ghcide/`

[siddharth-krishna]

Your environment

Which OS do you use?
MacOS 11.7.10 and 14
Which version of GHC do you use and how did you install it?
9.2.8 via ghcup (0.1.22.0)
How is your project built (alternative: link to the project)?
cabal (or nix + cabal)
https://github.com/plow-technologies/inferno

Which LSP client (editor/plugin) do you use?
vscode (v1.87.2) + Haskell plugin (v2.4.3)
Which version of HLS do you use and how did you install it?
2.7.0.0 via ghcup
Have you configured HLS in any way (especially: a hie.yaml file)?
No

Steps to reproduce

I cannot reproduce it myself deterministically, but it happens so often that I'm opening a bug report. Today I tried on a fresh laptop, fresh ghcup + ghc + hls install, fresh install of vscode's Haskell plugin, and within an hour I saw this error again. Here's the steps:

• Install ghcup using official instructions
• Install ghc 9.2.8 and hls 2.7.0.0 using ghcup
• Install vscode and Haskell plugin
• Wait for HLS to startup, find ghc and hls using ghcup, and build the project. It all works perfectly for a while.
• But at some point, some files start to show an error on the first line that it cannot find a .hi.core file in ~/.cache/ghcide/...

Expected behaviour

No such error.

Actual behaviour

I see a red squiggle on the first line of the file, with the error:

/Users/sid/.cache/ghcide/inferno-core-0.11.1.0-inplace-bdea44f530a52e915c4b2a4fb12efa71e6fd5f24/Inferno/Infer.hi.core: getFileStatus: does not exist (No such file or directory)

Debug information

The vscode output window for Haskell shows some errors, but I don't know if they are related:

2024-03-21T13:20:36.759358Z | Warning | No plugin handles this "textDocument/semanticTokens/full" request.
[Error - 15:20:36] Request textDocument/semanticTokens/full failed.
  Message: No plugins are available to handle this SMethod_TextDocumentSemanticTokensFull request.
 Plugins installed for this method, but not available to handle this request are:
semanticTokens is disabled globally in your config.
  Code: -32601 
[Error - 15:23:06] Request textDocument/foldingRange failed.
  Message: codeRange: Rule Failed: GetCodeRange
  Code: -32803 
...

Thank you for all your awesome work 🙌

---

EDIT: Clearing the ~/.cache/ghcide/ and ~/.cache/hie-bios/ directories helps for a while, but the error is back soon.

[avdv]

I also hit this with our project. I am using hls 2.0.0.0, GHC 9.6.3 and VSCodium 1.84.2 and haskell plugin 2.4.3.

I am using a hie-bios program integrating with buck2 in a multi-component project.

For me this usually happened when opening a file from a component that wasn't yet loaded:

2024-03-25T08:23:57.627861Z | Info | Interface files cache directory: /home/claudio/.cache/ghcide/main-a44446a21b39e1c2ce68d3d40c068a2837accb5c
2024-03-25T08:23:57.628255Z | Info | Interface files cache directory: /home/claudio/.cache/ghcide/main-a44446a21b39e1c2ce68d3d40c068a2837accb5c
2024-03-25T08:23:57.628288Z | Info | Making new HscEnv. In-place unit ids: [main, main]
2024-03-25T08:23:57.667905Z | Debug | New component cache HscEnvEq: (([],Just HscEnvEq 181),fromList [("/home/claudio/source/project/hie.yaml",Just 2024-03-21 14:13:46.823942506 UTC)])
2024-03-25T08:23:57.722783Z | Debug | New component cache HscEnvEq: (([],Just HscEnvEq 182),fromList [("/home/claudio/source/project/hie.yaml",Just 2024-03-21 14:13:46.823942506 UTC)])

... # open file

2024-03-25T08:26:58.376627Z | Info | Interface files cache directory: /home/claudio/.cache/ghcide/main-c3644eb0959937fb5029a2a3a9276a46dd6cd014
2024-03-25T08:26:58.377957Z | Info | Interface files cache directory: /home/claudio/.cache/ghcide/main-c3644eb0959937fb5029a2a3a9276a46dd6cd014
2024-03-25T08:26:58.378356Z | Info | Interface files cache directory: /home/claudio/.cache/ghcide/main-c3644eb0959937fb5029a2a3a9276a46dd6cd014
2024-03-25T08:26:58.378414Z | Info | Making new HscEnv. In-place unit ids: [main, main, main]
2024-03-25T08:26:58.415455Z | Debug | New component cache HscEnvEq: (([],Just HscEnvEq 459),fromList [("/home/claudio/source/project/hie.yaml",Just 2024-03-21 14:13:46.823942506 UTC)])
2024-03-25T08:26:58.435560Z | Debug | New component cache HscEnvEq: (([],Just HscEnvEq 460),fromList [("/home/claudio/source/project/hie.yaml",Just 2024-03-21 14:13:46.823942506 UTC)])
2024-03-25T08:26:58.454076Z | Debug | New component cache HscEnvEq: (([],Just HscEnvEq 461),fromList [("/home/claudio/source/project/hie.yaml",Just 2024-03-21 14:13:46.823942506 UTC)])

Seems like every component gets a new cache directory each time. Is this to be expected?

[jhrcek]

This behavior should have been made less likely after #4076

Though the bug is still present and we're tracking it in #4093

I was trying to find the exact place in the code where the .hi.core file is actually written but so far failed to find it. It seems there's a race between the code that writes that file and the code that checks the timestamp on it.
@wz1000 is it possible that the code writing .hi.core files runs in separate thread from the code that checks the timestamp on it?

Seems like every component gets a new cache directory each time. Is this to be expected?

I think this is the standard behavior. When you include module from different component, cabal needs a different set of flags (coming up with cabal flags to make the project build is the job of hie-bios) to be able to build the project and the flags are reflected in the hash, which is appended to the directory name, so that's why you see new directory being created in the cache dir.

[fendor]

Thank you for the bug report! @wz1000 will have a closer look at this issue.

[soulomoon]

happen in HLS codebase too, it is very common if we are using the multi-repl in cabal 3.12

/Users/ares/.cache/ghcide/ghcide-2.9.0.0-inplace-acd8748a3527adb2c9c8b8ab003c11596c14c67f/Development/IDE/GHC/CoreFile.hi.core: getFileStatus: does not exist (No such file or directory)

[soulomoon]

Some how it does not write out some files. I wonder if only FOI branch would write out the *.hi.core

exact place in the code where the .hi.core file is actually written but so far failed to find it

The core file is writtern at writeCoreFileIfNeeded ? @jhrcek

[soulomoon]

The fail case would be the following,

• open file A and A' core file would be saved to the first computed setCacheDirs using the hashed of the cacheDirOpts by the time.
• open file B, the hashed of cacheDirOpts changed and GetModSummary would pick up another cache dir location
• reading core file failed.