Haddock/GHC/C Pre Processor interactions on Windows

[Neil Mitchell]

Hi,

I've tracked down a bug, involving newline characters that is the
combination of GHC and Haddock, but involves the C Pre Processor -
hence sending the bug report for general discussion to everyone
concerned first. I suspect this bug is Windows only.

Given the file (UNIX \n or PC \r\n format):

------------------------
module Test where

-- | > test
test :: a
test = undefined
--------------------------

When I run "haddock --hoogle --optghc=-XCPP Test" (much like Cabal
does), I get back the following Hoogle file:

--------------------------
-- Hoogle documentation, generated by Haddock\r\n
-- See Hoogle, http://www.haskell.org/hoogle/\r\n
\r\n
\r\n
@package test\r\n
@version 0\r\n
\r\n
module Test\r\n
\r\n
-- | <pre>\r\n
--   test\r\r\n
--   </pre>\r\n
test :: a\r\n
---------------------------------

With explicit \r\n's inserted to see the issue. The issue is 3 lines
from the bottom, \r\r\n, which isn't a valid line ending, and makes
this text file rather weird. Similarly, if I don't specify --hoogle,
the generated Test.html has the fragment:

><PRE\r\n
> test\r\r\n
</PRE\r\n

Although this is rendered as HTML, so never becomes visible in a browser.

If you remove the -optghc=-XCPP then the problem no longer happens.
The problem also only occurs just at the end of a <pre> block, no
where else. I also tried dumping the intermediate CPP result, but that
looks fine, and contains a set of consistent \r\n line endings.

I've currently hacked around this with a filter (/= '\r') in the
Hoogle processing code, but this is just patching over the bug, not
fixing it at its root. I have no idea if the bug is in Haddock, in
GHC, or in the GHC API's interactions.

Thanks

Neil