New-pipeline: GHCi no longer works

[TravisCardwell]

Description

Attempting to start a GHCi session using cabal repl fails with errors like the following:

[ 56 of 155] Compiling Data.Array.Accelerate.Pattern.Ordering ( src/Data/Array/Accelerate/Pattern/Ordering.hs, interpreted )
ghc-9.4.8: ^^ Could not load 'accelerate_buffer_byte_size', dependency unresolved. See top entry above.


<no location info>: error:

GHC.ByteCode.Linker: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  accelerate_buffer_byte_size
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
  https://www.haskell.org/ghc/reportabug

Function accelerate_buffer_byte_size is defined in cbits/memory.c. It is used in Array.Buffer (abridging module names for brevity), bound by function memoryByteSize, and used by functions bufferFromPtr and liftBufferData.

The Pattern modules all result in such errors. These modules are implemented using the Pattern.TH module, which imports Smart, which imports Representation.Array, which imports the above Array.Buffer module. I confirmed that the Array.Buffer module is being built before the Pattern modules.

The foreign dependencies in Array.Buffer are loaded using addForeignFilePath, referencing note [linking to .c files] in Debug.Internal.Flags.

We use Template Haskell to tell GHC which .c files need to be compiled for a particular module, rather than relying on Cabal as is traditional. Using Cabal:

• loading Accelerate into GHCi only works after compiling the entire package (which defeats the purpose), presumably because the .c files are compiled last. This would often lead to errors such "can not find symbol __cmd_line_flags" etc.

• Cabal would refuse to re-compile .c files when changing command line flags, see: C source files are not recompiled when cc-options change haskell/cabal#4937

• Linking problems also prevented us from using Template Haskell in some locations, because GHC was unable to load the project into the interpreter to run the splices.

Note that for this fix to work in GHCi we also require modules using it to be loaded as object code.

I tried using Stack (stack repl), and it fails with the same errors.

I confirmed that the FFI in Array.Buffer (using cbits/memory.c and cbits/alloc.cpp) are the only new uses of addForeignFilePath; all other uses are in master. I confirmed that GHCi still works in master.

These new uses are probably failing due to some unfortunate interaction with Template Haskell in modules that depend on Array.Buffer. FFI and Template Haskell can be problematic!

Steps to reproduce

• Cabal: cabal repl
• Stack: stack repl

Expected behaviour

All modules should build and load.

Your environment

• Branch: new-pipeline
• Commit: 970ff19e
• GHC: ghc-9.4.8
• Cabal: 3.18.1.0
• Stack: 3.11.1
• OS: Arch Linux (Linux 7.2.3-arch1-2 x86_64)

[TravisCardwell]

One idea is to move all of the FFI bindings into an internal ffi library. The internal ffi library could continue to use addForeignFilePath to work around the foreign library recompilation issue. The public library could depend on the internal ffi library, and linking should be handled correctly even when using Template Haskell.

Note that this could also make things work better with HLS and ghcid. Currently, CPP conditions are used to guard foreign imports. Using an internal library would separate the foreign imports from HLS/ghcid processing.

Since the ffi library would be internal, raising the Cabal lower bound should not be required.

I found an issue with this idea, however: internal libraries cannot be used with build-type Custom. We are using build-type Custom to manage the foreign (C++) Tracy dependency, both fetching sources and building. I have mentioned elsewhere that fetching sources like that can be problematic. Perhaps we should discuss the design regarding Tracy and determine if the Custom build is the best thing to do.

If we continue to use the Custom build, the internal ffi library idea is not viable.