| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a proper Haddock module header to each module, with a more finegrained
copyright. If you feel mis-accreditted, please correct any copyright notice!
The maintainer field is set to haddock@projects.haskell.org.
Next step is to add a brief description to each module.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The module name is already written in the beginning of the message, as
seems to be the convention in Haddock. Perhaps not so clear, but we
should change it everywhere in that case. Leaving it as it is for now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We tried to filter out subordinates that were already exported through their parent.
This didn't work properly since we were in some cases looking at the
grand-parent and not the parent. We now properly compute all the parent-child
relations of a declaration, and use this information to get the parent of a
subordinate.
We also didn't consider record fields with multiple parents. This is now
handled correctly.
We don't currently support separately exported associated types. But when we
do, they should be handled correctly by this process too.
Also slightly improved the warning message that we give when filtering out
subordinates.
|
| |
|
|
|
|
| |
See note in the source code for more info.
|
| |
|
| |
|
|
|
|
|
| |
We now filter out everything that is not a proper Haskell declaration before
collecting the docs and attaching them to declarations.
|
|
|
|
| |
This patch was contributed by Joachim Breitner (nomeata).
|
| |
|
|
|
|
|
| |
This seems to have regressed since a refactoring that was
part of the 2.3.0 release.
|
|
|
|
|
|
|
| |
This fixes GHC ticket 2746.
In order to also link to the exported subordinate names of a declaration, we
need to re-introduce the sub map in the .haddock files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of a complicated calculation of visible names out of GHC's export
items, we can get them straight out of the already calculated ExportItems. The
ExportItems should represent exactly those items that are visible in an
interface.
If store all the exported sub-names in ExportDecl instead of only those with
documentation, the calculation becomes very simple. So we do this change as
well (should perhaps have been a separate patch).
This should fix the problem with names from ghc-prim not appearing in the link
environment.
|
|
|
|
|
| |
Fixes a crash when processing modules without export lists containing named
docs.
|
|
|
|
|
| |
Remove commented out half-done type instance support, and remove DeclWithDoc
synonym.
|
|
|
|
| |
It is not needed now that we store subordinate names in the DeclInfo map.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were not getting docs for re-exported class methods. This was because we
were looking up the docs in a map made from the declarations in the current
module being rendered. Obviously, re-exported class methods come from another
module.
Class methods and ATs were the only thing we were looking up using the doc map,
everything else we found in the ExporItems. So now I've put subordinate docs
in the ExportItem's directly, to make things a bit more consistent.
To do this, I added subordinates to the the declarations in the declaration
map. This was easy since we were computing subordinates anyway, to store
stand-alone in the map. I added a new type synonym 'DeclInfo', which is what we
call what is now stored in the map.
This little refactoring removes duplicate code to retrieve subordinates and
documentation from the HsGroup.
|
|
|
|
|
|
|
|
|
|
|
| |
The only place in the code where we want the subordinates for a declaration is
right after having looked up the declaration in the map.
And since we include subordinates in the map, we might as well take the
opportunity to store those subordinates that belong to a particular declaration
together with that declaration.
We also store the documentation for each subordinate.
|
| |
|
| |
|
| |
|