Ticket #83 (closed enhancement: fixed)

Opened 6 years ago

Last modified 9 months ago

Better parse error messages when parsing the contents of Haddock comments

Reported by: waern Owned by:
Priority: major Milestone:
Version: 2.4.1 Keywords:
Cc:

Description

Needs to be done in GHC.

Change History

Changed 6 years ago by waern

  • type changed from defect to enhancement

Changed 6 years ago by 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.

Changed 6 years ago by 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).

Changed 6 years ago by waern

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

Changed 2 years ago by anonymous

  • milestone 2.6.0 deleted

Milestone 2.6.0 deleted

Changed 9 months ago by Fūzetsu

  • status changed from new to closed
  • resolution set to fixed

Considering you should never get parse failures after 2.14.0, this can now be closed.

Note: See TracTickets for help on using tickets.