More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this:
(Answering my own message) Having done some more testing with ghc-6.8.1 and ghc-6.6.1 and cabal's 1.1.6.2 and 1.3, I've realised that the cpp optP-P option in Cabal-1.3 is suppressing the # n lines, so that means the {-# LINE 1 "Test.lhs" #-} comment does indeed end up immediately preceding the first real line of the program (thus causing unlit to spit the dummy). I've also noticed that the options passed from cabal-1.1.6.2 to the ghc cpp phase do NOT include -x hs, so ghc unlits the file before cabal then tries to unlit it. Surely this cannot work, and indeed it does not, because the resulting .hs file contains no code. I'm of a mind to fix two things in cabal: - the haddock command runs unlit first, THEN cpp - the unlit module preserves comments, for the benefit of haddock I already have these done in my local Cabal-1.3, so creating patches ought to be straightforward. I've only tested with ghc on Windows though. Comments? Thanks, Alistair