hls seems to be building dyn_o files for deps that are already built by cabal

[lf-]

I am trying to point hls at itself while debugging an issue I am going to try fixing before filing a bug about it. I am using nix develop and the value of cabal exec which haskell-language-server as my language server in the project config.

HLS is taking a hot minute to start everything, as it is recompiling ghcide for a second time.

In the output, I find this:

2022-08-11T17:27:39.595829Z | Info | No log file specified; using stderr.
2022-08-11T17:27:39.596146Z | Info | haskell-language-server version: 1.7.0.0 (GHC: 9.0.2) (PATH: /Users/jade/co/haskell-language-server/dist-newstyle/build/aarch64-osx/ghc-9.0.2/haskell-language-server-1.7.0.0/x/haskell-language-server/build/haskell-language-server/haskell-language-server) (GIT hash: 524ef152342f37ac524e4da1e419d164316c7c8f)
2022-08-11T17:27:39.596594Z | Info | Directory: /Users/jade/co/haskell-language-server
2022-08-11T17:27:39.596702Z | Info | Starting (haskell-language-server) LSP server...
  GhcideArguments {argsCommand = LSP, argsCwd = Nothing, argsShakeProfiling = Nothing, argsTesting = False, argsExamplePlugin = False, argsDebugOn = False, argsLogFile = Nothing, argsThreads = 0, argsProjectGhcVersion = False}
  PluginIds: [ pragmas
             , floskell
             , fourmolu
             , tactics
             , ormolu
             , stylish-haskell
             , rename
             , retrie
             , callHierarchy
             , class
             , haddockComments
             , eval
             , importLens
             , qualifyImportedNames
             , refineImports
             , moduleName
             , hlint
             , splice
             , alternateNumberFormat
             , codeRange
             , changeTypeSignature
             , gadt
             , ghcide-hover-and-symbols
             , ghcide-code-actions-imports-exports
             , ghcide-code-actions-type-signatures
             , ghcide-code-actions-bindings
             , ghcide-code-actions-fill-holes
             , ghcide-completions
             , ghcide-type-lenses
             , ghcide-core
             , LSPRecorderCallback ]
2022-08-11T17:27:39.598169Z | Info | Logging heap statistics every 60.00s
 2022-08-11T17:27:39.635959Z | Info | Staring LSP server...
If you are seeing this in a terminal, you probably should have run WITHOUT the --lsp option!
2022-08-11T17:27:39.637180Z | Info | Started LSP server in 0.00s
2022-08-11T17:27:41.863755Z | Info | Registering IDE configuration: IdeConfiguration {workspaceFolders = fromList [NormalizedUri (-2384363926652971649) "file:///Users/jade/co/haskell-language-server"], clientSettings = hashed (Just (Object (fromList [])))}
2022-08-11T17:28:39.599530Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11T17:29:39.600780Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11T17:30:39.602085Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11T17:31:39.608453Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11T17:32:39.609701Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11T17:33:39.610756Z | Info | Live bytes: 0.00MB Heap size: 0.00MB
2022-08-11 10:34:25.533627 [ThreadId 120] INFO hie-bios:	[34 of 80] Compiling Development.IDE.Core.RuleTypes ( src/Development/IDE/Core/RuleTypes.hs, /Users/jade/.cache/hie-bios/dist-haskell-language-server-5bb4a69190c0164cfda39b590a32fc9e/build/aarch64-osx/ghc-9.0.2/ghcide-1.7.0.1/build/Development/IDE/Core/RuleTypes.o, /Users/jade/.cache/hie-bios/dist-haskell-language-server-5bb4a69190c0164cfda39b590a32fc9e/build/aarch64-osx/ghc-9.0.2/ghcide-1.7.0.1/build/Development/IDE/Core/RuleTypes.dyn_o )

This seems surprising to me given that I have already compiled hls so all those dependencies have already been built in the dist-newstyle directory of the hls checkout, and seemingly with dyn_o files as required?

Your environment

Which OS do you use? MacOS 12.4 aarch64

Which version of GHC do you use and how did you install it? 9.0.4, from the nix develop of the hls project

How is your project built (alternative: link to the project)?

Which LSP client (editor/plugin) do you use? coc

Have you configured HLS in any way (especially: a hie.yaml file)? I haven't done anything to my checkout, so it's whatever is in master.

Steps to reproduce

Start hls on itself as above with no things in the ~/.cache/.... directory.

I am looking at plugins/hls-hlint-plugin/src/Ide/Plugin/Hlint.hs but there are probably others.

Expected behaviour

No rebuild of the dyn_o files that already were built by cabal.

Actual behaviour

hls painstakingly rebuilds a bunch of stuff

Debug information

commit 524ef152342f37ac524e4da1e419d164316c7c8f

[pepeiborra]

You are assuming that HLS reuses the build artifacts from Cabal, but it does not.

Where does this assumption come from? Asking in case we need to review our docs.

[lf-]

Hmm, maybe it is a bad assumption. I had assumed it because of load times: it did not feel, time wise, like a full compilation was happening on my extremely large work codebase before loading hls, but maybe i was just mistaken.

... looks and indeed that is the case; there seem to be no dyn_o files for the work project package in ~/.cache/hie-bios. Interesting. (tbf there is almost certainly something cursed being done with the Mercury haskell language server build given their history with being on the very edge of HLS perf usability)

Is there a reason the artifacts couldn't be reused?

[wz1000]

Is there a reason the artifacts couldn't be reused?

yes, sharing the build directory means that a cabal build while HLS is running causes race conditions as both HLS and cabal are accessing the build directory at the same time.

[michaelpj]

I think this is working as expected. I think we could put this in our docs, but I suspect most people won't care!