| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The Xhtml backend has special markup for that, Hoogle and LaTeX reuse
what we have for DocEmphasis.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
(A bug that should have been fixed long ago.)
|
|
|
|
|
|
|
|
|
|
|
| |
renaming time.
Previously this was done in the backends.
Also, warn when a doc comment refers to something that is in scope but which we
don't have the .haddock file for.
These changes mean we can make DocIdentifier [a] into DocIdentifier a.
|
|
|
|
|
|
|
|
|
| |
This big patch implements a kind-polymorphic core for GHC. The current
implementation focuses on making sure that all kind-monomorphic programs still
work in the new core; it is not yet guaranteed that kind-polymorphic programs
(using the new -XPolyKinds flag) will work.
For more information, see http://haskell.org/haskellwiki/GHC/Kinds
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
src/Haddock/Convert.hs
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
darcs format (followed by a conflict resolution):
commit 6f92cdd12d1354dfbd80f8323ca333bea700896a
Merge: f420cc4 28df3a1
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Thu May 19 17:54:34 2011 +0100
Merge remote branch 'origin/master' into ghc-generics
commit 28df3a119f770fdfe85c687dd73d5f6712b8e7d0
Author: Max Bolingbroke <batterseapower@hotmail.com>
Date: Sat May 14 22:37:02 2011 +0100
Unicode fix for getExecDir on Windows
commit 89813e729be8bce26765b95419a171a7826f6d70
Merge: 6df3a04 797ab27
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Mon May 9 11:55:17 2011 +0100
Merge branch 'ghc-new-co'
commit 6df3a040da3dbddee67c6e30a892f87e6b164383
Author: Ian Lynagh <igloo@earth.li>
Date: Sun May 8 17:05:50 2011 +0100
Follow changes in SDoc
commit f420cc48b9259f0b1afd2438b12f9a2bde57053d
Author: Jose Pedro Magalhaes <jpm@cs.uu.nl>
Date: Wed May 4 17:31:52 2011 +0200
Adapt haddock to the removal of HsNumTy and TypePat.
commit 797ab27bdccf39c73ccad374fea265f124cb52ea
Merge: 1d81436 5a91450
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Mon May 2 12:05:03 2011 +0100
Merge remote branch 'origin/master' into ghc-new-co
commit 1d8143659a81cf9611668348e33fd0775c7ab1d2
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Mon May 2 12:03:46 2011 +0100
Wibbles for ghc-new-co branch
commit 5a91450e2ea5a93c70bd3904b022445c9cc82488
Author: Ian Lynagh <igloo@earth.li>
Date: Fri Apr 22 00:51:56 2011 +0100
Follow defaultDynFlags change in GHC
|
|
|
|
| |
Silly, but nice with some consistency :-)
|
| |
|
| |
|
| |
|
|
|
|
| |
It's not used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
..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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Instead of explicitly making some binders Undocumented, treat all names the
same way (that is, try to find a Documented name).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
The support for DocPic was merged into the GHC source long ago,
but the support in Haddock was forgotten. Thanks Peter Gavin for
submitting this fix!
|
|
|
|
|
|
|
|
|
| |
We want to be able to render instances as separate declarations. So we remove
the Name argument of ExportDecl, since instances are nameless.
This patch also contains the first steps needed to gather type family instances
and display them in the backend, but the implementation is far from complete.
Because of this, we don't actually show the instances yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were creating a doc map, a declaration map and a list of entities
separately by going through the HsGroup. These structures were all used
to build the interface of a module.
Instead of doing this, we can start by creating a list of declarations
from the HsGroup, then collect the docs directly from this list
(instead of using the list of entities), creating a documentation map.
We no longer need the Entity data type, and we can store a single
map from names to declarations and docs in the interface, instead of
the declaration map and the doc map.
This way, there is only one place where we filter out the declarations
that we don't want, and we can remove a lot of code.
Another advantage of this is that we can create the exports directly
out of the list of declarations when we export the full module contents.
(Previously we did a look up for each name to find the declarations).
This is faster and removes another point where we depend on names to
identify exported declarations, which is good because it eliminates
problems with instances (which don't have names).
|
| |
|
| |
|
| |
|
| |
|
| |
|