Improve template haskell support (upstream fix and workaround for compiler crashes)

[jneira]

Description of the problem (from #469 (comment)):

GHC has its own dynamic linker, in the rts, and it gets used in certain cases:

• when GHC the binary is linked statically, by GHCI and TH
• when ghc the library is linked statically, by TH and the ghc interactive api
  Implementing a dynamic linker with support for >=3 platforms is a risky and complex exercise. Fortunately there is an easy opt-out (-dynamic) but unfortunately that opt-out makes distribution much harder, and the precompiled HLS binaries are statically linked.

---

Hot to check if you hls binary is using the ghc dynamic linker (from #1982 (comment)):

/path/to/haskell-language-server  +RTS --info | grep "RTS way" | grep dyn && echo "Dynamic" || echo "Static

---

• We have plenty of serious bugs involving the use of template haskell: https://github.com/haskell/haskell-language-server/issues?q=is%3Aissue+is%3Aopen++label%3A%22type%3A+template+haskell+related%22+
• Surely there would be some more that are not diagnosed
• Surely we cant tacke all of them in a unified way
• But i hope there would be something we can do to improve the handling in a global way
• Maybe we could take advantage of gsoc 2021 to make progress on it although it could not be the more attractive work

@pepeiborra @wz1000 could we sketch what could be the needed changes (mainly in ghcide i suppose) to improve it? is it even a good idea?

[pepeiborra]

I don't use TH so I cannot really help much. My understanding is that the main issue is a bug in the GHC static linker for Mac OS, which causes segfaults. The best way to address this would be to enable using the system linker even when the ghc package is statically linked, lifting the restriction described here. But this is a GHC change and it would need some speccing out and a qualified mentor.

[jneira]

So maybe @wz1000?, what do you think about this possible line of work?

[jneira]

I am gonna remove the label for now, as this dont have an actionable outcome

[jneira]

All issues seems to be related with the ghc dynamic linker so i would label this as blocked upstream on https://gitlab.haskell.org/ghc/ghc/-/issues/19021 (opened in #469) and with the generic workaround of compile hls from source with this config in cabal.project or cabal.project.local

package haskell-language-server
  ghc-options: -dynamic

[jneira]

It seems a way to fix template haskell handling in ghc itself has been opened: see #2000 (comment)
The link in the ghc issue tracker would be https://gitlab.haskell.org/ghc/ghc/-/issues/20628

[GavinRay97]

All issues seems to be related with the ghc dynamic linker so i would label this as blocked upstream on gitlab.haskell.org/ghc/ghc/-/issues/19021 (opened in #469) and with the generic workaround of compile hls from source with this config in cabal.project or cabal.project.local

package haskell-language-server
  ghc-options: -dynamic

@jneira I asked @jkachmar and this should also be an easy option if you use ghcup right?

$ ghcup compile hls --patchdir $DYNAMIC_PATCHES -v $HLS_VERSION $GHC_VERSION

Where in the patch dir would be this (or something)?

hls-compile-dynamic-cabal.patch

index d1d06d9..e029c9d 100644
--- a/cabal.project
+++ b/cabal.project
@@ -36,6 +36,9 @@ package *
   ghc-options: -haddock
   test-show-details: direct
 
+package haskell-language-server
+  ghc-options: -dynamic

 write-ghc-environment-files: never

 index-state: 2021-10-04T02:41:06Z