| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This setup makes more sense since when we add value bindings to the
processed declarations (for type inference), we will have multiple
declarations which should share documentation. Also, we already have
a separate doc map for instances which we can now merge into the
main doc map. Another benefit is that we don't need the DeclInfo
type any longer.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- Docs don't get attached to the next top-level with signature by
mistake.
- If there's an export list and the top-level is part of it,
its doc comment shows up in the documentation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From 6fc71d067738ef4b7de159327bb6dc3d0596be29 Mon Sep 17 00:00:00 2001
From: Michal Terepeta <michal.terepeta@gmail.com>
Date: Sat, 14 May 2011 19:18:22 +0200
Subject: [PATCH] Follow the change of TypeSig in GHC.
This follows the change in GHC to make TypeSig take a list
of names (instead of just one); GHC ticket #1595. This
should also improve the Haddock output in case the user
writes a type signature that refers to many names:
-- | Some comment..
foo, bar :: ...
will now generate the expected output with one signature for
both names.
|
| |
|
| |
|
|
|
|
|
| |
The documentation describes how we want this function to eventually behave,
once we have fixed a few problems with the current implementation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
A module's haddockable items are its exports and the module itself.
The output is lightly formatted so you can align the :'s and sort
for readability.
|
|
|
|
| |
We can get everything we need directly from TypecheckedModule.
|
| |
|
|
|
|
| |
Silly, but nice with some consistency :-)
|
| |
|
|
|
|
|
|
|
|
| |
No link was generated for 'Addr#' in a doc comment. The reason was simply that
the identifier didn't parse. We were using parseIdentifier from the GHC API,
with a parser state built from 'defaultDynFlags'. If we pass the dynflags of
the module instead, the right options are turned on on while parsing the
identifer (in this case -XMagicHash), and the parse succeeds.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementing this was a little trickier than I thought, since we need to match
up instances from the renamed syntax with instances represented by
InstEnv.Instance. This is due to the current design of Haddock, which matches
comments with declarations from the renamed syntax, while getting the list of
instances of a class/family directly using the GHC API.
- Works for class instances only (Haddock has no support for type family
instances yet)
- The comments are rendered to the right of the instance head in the HTML output
- No change to the .haddock file format
- Works for normal user-written instances only. No comments are added on
derived or TH-generated instances
|
| |
|
| |
|
| |
|
|
|
|
| |
see the long comment in the patch for why I did it this way :-)
|
|
|
|
| |
dep of inferenced-decls fix
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While breaking the format, I took the opportunity to unrename the
DocMap that's saved to disk, because there's really no reason that
we want to know what *another* package's favorite place to link a
Name to was. (Is that true? Or might we want to know, someday?)
Also, I added instance Binary Map in InterfaceFile.
It makes the code a little simpler without changing anything of
substance. Also it lets us add another Map hidden inside another
Map (fnArgsDocs in instDocMap) without having really-convoluted
serialization code. Instances are neat!
I don't understand why this change to InterfaceFile seemed to
subtly break binary compatibility all by itself, but no matter,
I'll just roll it into the greater format-changing patch. Done!
|
|
|
|
|
|
|
| |
..on top of the lexParseRn work.
This patch doesn't change the InstalledInterface format, and thus,
it does not work cross-package, but that will be easy to add
subsequently.
|