On 10/04/14 17:52, Christiaan Baaij wrote:
But that's unwanted, as those backslashes show up in GHC(i) messages. So: how do I get haddock to not parse my '<^>' operator as a link/URL?
Hm, strange, technically we parse identifiers first and links second so this should work without a problem unless Haddock doesn't recognise it as an identifier.
I actually now notice in the parser that we don't consider ^ to be a valid symbol so that's probably the culprit! Good catch, if that's actually the case here then you can expect it to be fixed in the next release, perhaps with 7.8.3 or something. Unfortunately the way we do identifier parsing now is that we slurp everything that looks like a valid identifier and afterwards we ask GHC to actually tell us if it's it's something we know about. It seems like a bug caused by me not being careful when reading the relevant part of the report, deepest apologies! I do wish we had a better way of parsing these identifiers but I can't think of one.
It never came to mind that '^' was the actual culprit :-) Now that I know that it's a (potential) bug, I'll just keep my eye on ghc-commit and wait for the bugfix. I'm used to running ghc-HEAD anyway.
Ah. I'll probably push out a fix tomorrow then and you can grab that.
Also, is it not possible to update my haddock seperate from GHC?
You should be able to simply cabal install haddock as long as you are using the GHC version it expects. For Haddock HEAD (to-be 2.15.0), you need GHC 7.9: you can just go to utils/haddock in the GHC tree and run cabal install there (or clone outside of the tree or whatever). For the 2.14.x releases, we require 7.8.x.
-- Christiaan
-- Mateusz K.