haddock-2.3.0 literate comments discarded from .lhs input

Alistair Bayley

6 Feb 2009 6 Feb '09

4:24 a.m.

I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair@abayley.org Stability : stable Portability : portable Test case for Haddock.

...

module Test.Haddock ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed

$named_block This is some hadock documentation. -------------------------------------------------- This fails with: [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' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair@abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair

Show replies by date

David Waern

6 Feb 6 Feb

5:18 a.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

2009/2/6 Alistair Bayley :

...

I have this test case for Haddock (2.3.0):

--------------------------------------------------

| Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair@abayley.org Stability : stable Portability : portable

Test case for Haddock.

...
module Test.Haddock ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed

$named_block

This is some hadock documentation.

--------------------------------------------------

This fails with:

[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 :) David

Alistair Bayley

5:35 a.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

...

...
[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 Alistair

David Waern

5:48 a.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

2009/2/6 Alistair Bayley :

...

...
...
[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. David

Duncan Coutts

5:27 p.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:

...

2009/2/6 Alistair Bayley :

...
...
...
[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

Alistair Bayley

7 Feb 7 Feb

4:31 p.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

2009/2/6 Duncan Coutts :

...

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.

In Distribution.Simple.Haddock, in the haddock function we have: withLib pkg_descr () $ \lib -> do let bi = libBuildInfo lib modules = PD.exposedModules lib ++ otherModules bi inFiles <- getLibSourceFiles lbi lib unless isVersion2 $ mockAll bi inFiles So I guess the easiest thing to do right now is remove the "unless isVersion2 $" . I'm testing this at the moment, so when I get it working (or not) I'll let you know, and maybe send a patch. Alistair

Andrea Vezzosi

8 Feb 8 Feb

1:18 p.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

I did work on this and i simplified the code a lot fixing inconsistencies and making more explicit what how each component contributes to the arguments to haddock. Aside from this, should we also do the unliting and cpp from Cabal on the sources passed to HsColour? On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts wrote:

...

On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:

...
2009/2/6 Alistair Bayley :

...
...
...
[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

Duncan Coutts

7:33 p.m.

New subject: haddock-2.3.0 literate comments discarded from .lhs input

On Sun, 2009-02-08 at 19:18 +0100, Andrea Vezzosi wrote:

...

I did work on this and i simplified the code a lot fixing inconsistencies and making more explicit what how each component contributes to the arguments to haddock.

Much appreciated.

...

Aside from this, should we also do the unliting and cpp from Cabal on the sources passed to HsColour?

Hmm. I thought it did already :-) Well, I know it runs happy, hsc2hs etc. Someone was complaining the other day that the hscolour output run on the result of happy is not really readable, but then it's not clear if running it on the happy input would be any better. For the particular case of .lhs and cpp, I hope we'd get better hscolour output by not running unlit or cpp first. Malcolm says it'll at least do something. So it seems worth checking which ends up looking more useful. Duncan

...

On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts

...
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.

5947

Age (days ago)

5950

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Alistair Bayley
Andrea Vezzosi
David Waern
Duncan Coutts

haddock-2.3.0 literate comments discarded from .lhs input

tags

participants (4)