haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:
> 2009/2/6 Alistair Bayley <alistair at abayley.org>:
> >>> [1 of 1] Compiling Test.Fail        ( Test\Fail.hs, Test\Fail.o )
> >>>
> >>> Test\Fail.hs:11:26:
> >>>    Can't make a derived instance of `Typeable Fail'
> >>>      (You need -XDeriveDataTypeable to derive an instance for this class)
> >>>    In the data type declaration for `Fail'
> >>
> >> Are you processing the above module but it is called Test.Fail in
> >> reality? Have you stripped out a deriving statement from the example
> >> above? I'm very confused by this message :)
> >
> >
> > Sorry, my mistake. I pasted the error message from a different
> > problem. This is the error I get from haddock:
> >
> > C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs
> > Cannot find documentation for: $named_block
> 
> Okay, then I understand.
> 
> My guess is (without looking at ghc code) that ghc just throws the
> literate comments away before lexing the file. This means that the
> Haddock comments won't be recognized.
> 
> As you say, there is also an unlitter in Cabal. I don't remember if it
> is invoked when using Haddock 2, but if it is, it would solve this
> problem.

Yes, against my better judgement the code in Cabal for haddock-2.x does
not run cpp or unliting like it does for haddock-0.x. Instead it assumes
that haddock-2.x will do all the cpp and unliting itself. Obviously this
mean the special unliting mode that Cabal provides is not usable with
haddock-2.x.

The solution is to do the pre-processing the same for haddock-0.x and
2.x. Generally the haddock code in Cabal is a horrible inconsistent
mess. I believe Andrea Vezzosi has been looking at rewriting it, which
is good news.

Duncan