fpco/ide-backend

Haddock generation does not include data files

Opened this issue · 3 comments

Example demonstrating the problem:

{-# LANGUAGE OverloadedStrings #-}
import IdeSession
import Data.Monoid

file1 = "{-# LANGUAGE TemplateHaskell #-}\n\
        \module Foo where\n\
        \import Data.FileEmbed\n\
        \foo = $(embedFile \"data.txt\")"
file2 = "module Data.ByteString where\n\
        \import Foo\n\
        \main = print foo"
file3 = "hello world"

update = updateSourceFile "Foo.hs" file1 <>
         updateSourceFile "Data/ByteString.hs" file2 <>
         updateDataFile "data.txt" file3 <>
         updateCodeGeneration True

main :: IO ()
main = do
    sess <- initSession defaultSessionInitParams defaultSessionConfig

    updateSession sess update print

    getSourceErrors sess >>= print

    ra <- runStmt sess "Data.ByteString" "main"
    let loop = do
            eres <- runWait ra
            case eres of
                Left bs -> print bs >> loop
                Right res -> print res
    loop

    updateSession sess buildDoc print

    distdir <- getDistDir sess
    readFile (distdir ++ "/doc/ide-backend-doc.stdout") >>= print
    readFile (distdir ++ "/doc/ide-backend-doc.stderr") >>= print

Since the source requires the data.txt file to be present to compile, I end up with the error message:

"\ndist/build/tmp-2521/src/Foo.hs:4:9:\n    Exception when trying to run compile-time code:\n      data.txt: openBinaryFile: does not exist (No such file or directory)\n    Code: embedFile \"data.txt\"\n    In the splice: $(embedFile \"data.txt\")\n"

I also ran into an issue at some point about conflicting module names with modules installed in the package database, but I can't reproduce it (that's why I named one of the modules here Data.ByteString).

Pinging @mgsloan

Regrettably, I can't see any test for generating haddocks in the presence of TH in the ide-backend testsuite, so the problem may be there from the start. I can't see any obvious flags to tweak and the code for buildExe and buildDoc is very similar so it's surprising one works (I assume) when another fails. Ditto for the non-unique file names.

For the record, I've just tested this example, and the bug is still there.