Preprocessors support

[berberman]

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 0.7.1.0 (GHC: 8.10.2) (PATH: /home/berberman/.cabal/store/ghc-8.10.2/haskell-language-server-0.7.1.0-1b853bbfb9efed2b28ed42e7c45d0977aeea9a80a3df9b1ce8cdbe96a4efaaf6/bin/haskell-language-server)
Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		Not found
ghc:		8.10.2

Which lsp-client do you use:

vscode

Describe your project (alternative: link to the project):
in cabal file:

build-tools-depends: hsc2hs

Steps to reproduce

Open a .hsc file, HLS didn't know it was a haskell source file.

Expected behaviour

HLS should be able to load .hsc (hsc2hs) and .chs (c2hs) files.

Actual behaviour

HLS ignore those files.

[mpickering]

It's not clear how easy this would be to support. I suppose hls works with the C Preprocessor so perhaps it should also work with hsc files? Can you load hsc and chs files into ghci normally?

[georgefst]

For the record, my current, clunky but useable, workflow for using C2HS with HLS, assuming there's only one .chs file we care about editing, is (EDIT: no longer working: #689 (comment)):

• If in a multi-package project, cd down to package's folder (i.e. don't run any of this from the root).
• Find how Cabal is invoking C2HS, by inspecting the output of cabal build -v | grep c2hs.
  • If we want tighter integration, the first step would be to work out exactly how, in general, to get those flags.
• Modify the --output-dir flag to point to the hie-bios cache. I'm not sure how to get this from HLS, but it should be easy to find manually in ~/.cache/hie-bios.
• Set up a file watcher to run the command on save, and touch all normal Haskell files in order to kick HLS in to action.

The end result looks something like this:

rebuild () { /home/gthomas/.cabal/store/ghc-9.2.3/c2hs-0.28.8-e-c2hs-fbbd87382de63429326105b3b6f8eb5253fc6809d8a468a54112f11a4c3e6ba8/bin/c2hs '--cpp=/usr/bin/gcc' '--cppopts=-E' '--cppopts=-D__GLASGOW_HASKELL__=902' '--cppopts=-Dlinux_BUILD_OS=1' '--cppopts=-Dx86_64_BUILD_ARCH=1' '--cppopts=-Dlinux_HOST_OS=1' '--cppopts=-Dx86_64_HOST_ARCH=1' '--cppopts=-I/usr/include/libevdev-1.0' '--cppopts=-include/home/gthomas/code/evdev/dist-newstyle/build/x86_64-linux/ghc-9.2.3/evdev-2.1.0/build/autogen/cabal_macros.h' '--include=/home/gthomas/code/evdev/dist-newstyle/build/x86_64-linux/ghc-9.2.3/evdev-2.1.0/build' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/process-1.6.13.2/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/unix-2.7.2.2/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/time-1.11.1.1/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/bytestring-0.11.3.1/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/base-4.16.2.0/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/ghc-bignum-1.2/include' '--cppopts=-I/home/gthomas/.ghcup/ghc/9.2.3/lib/ghc-9.2.3/include' --output-dir=$1 '--output=Evdev/LowLevel.hs' src/Evdev/LowLevel.chs ; }

while true ; do inotifywait -e CLOSE_WRITE src/Evdev/LowLevel.chs ; rebuild /home/gthomas/.cache/hie-bios/dist-evdev-419c9baeb83d09549865f4fc0550cb43/build/x86_64-linux/ghc-9.2.3/evdev-2.1.0/build ; find . -path ./dist-newstyle -prune -o -name '*.hs' -print | xargs touch ; done

The only real issue with this is that errors and warnings are linked to the output file (which HLS is unsurprisingly unable to load properly), rather than the original .chs file:

[berberman]

It's not clear how easy this would be to support. I suppose hls works with the C Preprocessor so perhaps it should also work with hsc files? Can you load hsc and chs files into ghci normally?

Those files can't be loaded directly in GHCi. Instead, we need run pre-processors (hsc2hs, alex, c2hs, etc.) to convert them from non-Haskell files into Haskell source files. cabal-install helps us with that: https://github.com/haskell/cabal/blob/master/Cabal/src/Distribution/Simple/PreProcess.hs

I don't know if it would be possible to extract the arguments of such build tools from Cabal, and It seems that the arguments involve package descriptions, which HLS don't have the access to. Perhaps we should generate the arguments for cabal cradle which needs pre-process in hie-bios, and run pre-processors in ghcide.

[anka-213]

HLS seems to "support" the LINE pragma (or maybe that's just GHC?), but seems to ignore the path component of it. When I open the (by hsc2hs) generated hs file inside .stack-work, I get all the errors and warnings, but on the wrong lines.

{-# LINE 62 "src/Original.hsc" #-}

If hls supported the path component of this pragma, I think this workflow would work as a workaround:

1. Trigger the preprocessor on file-watch (e.g. with stack build --file-watch or something narrower)
2. Open both the original file and the generated file in an editor
3. Make edits in the original and see all the warnings and errors there.

[michaelpj]

An additional issue with this is that any code actions which make edits to the file will likely do the wrong thing. In general this is a hard problem: we'd need to work out what un-preprocessed source would work. e.g. in the case of literate haskell we'd have to insert a leading >. We might be able to special case some examples like that, but it seems hard in general. Probably we should disable most code actions on preprocessed files.

[anka-213]

@michaelpj One possible way to prevent code actions from breaking code without disabling it completely for preprocessed files could be to check that the preprocessed version of the code snippet we want to modify exists verbatim in the expected location in the source file as well. That way, we will never change something unexpected. This would disable the code actions for Bird-style `>` lhs (until a special case to handle it is implemented), but still allow it for latex style `\begin{code}` lhs and alex/happy files, as long as the change doesn't span multiple blocks. It might be possible (but more difficult) to generically handle multiple blocks too. (This is assuming I haven't misunderstood how code actions works internally.)

[georgefst]

For the record, my current, clunky but useable, workflow for using C2HS with HLS (in a project with just one .chs file) is:

This no longer works. I just can't seem to convince HLS to pick up the changes at /home/gthomas/.cache/hie-bios/dist-evdev-419c9baeb83d09549865f4fc0550cb43/build/x86_64-linux/ghc-9.2.3/evdev-2.1.0/build/Evdev/LowLevel.hs. I can restart HLS, and changes are reflected, but that works without even running the commands above.

I'm not sure I've tried this between posting that comment and now, so that's a big window for when it stopped working. Does anyone have any idea what might have changed?