Better parse error messages when parsing the contents of Haddock comments

[waern]

Needs to be done in GHC.

[duncan]

Just having file names and line numbers would be good. For example I got this error:

haddock: parse error in doc string

Nothing else. No idea what is wrong, not even sure what file to look in.

Turns out it was due to this:

module Foo (
  -- * some top level section name
  something,

  -- **
  somethingElse,
  ) where

So it was just that I'd not filled in the subsection name yet. I presume that if there had been an error in the markup within that subsection name that it would have shown me the full thing. However since the problem was that it was blank, showing me the blank markup is rather confusing.

[waern]

Unfortunately, it will always give you this extremely bad error message if you're using GHC >= 6.10.

We have two regressions here:

• We used to "show" the AST of the markup, but that was removed during the SoC project (I can't remember why, ATM).

• With GHC < 6.10 we show the source location of the Haddock comment. When support for GHC 6.10 was added, an error handler was installed only around the typechecking phase, so we miss cases like this where (I think) an error is thrown during dependency chasing.

I will try to fix this second regression as soon as possible (hopefully in time for 2.4.2). But we should also:

• Pretty-print the Haddock comment
• Give exact source location (from within the Haddock-comment).

The two above enchancements should probably be done after we have moved the parser and lexer for Haddock comments from GHC back into Haddock (see #93).

[waern]

The second regression has been remedied. We now print the file, line and column where the comment is located.

[anonymous]

Milestone 2.6.0 deleted