| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is a quick and dirty hack to get rid of separately exported ATs.
We haven't decided how to handle them yet. No warning message is given.
|
| |
|
|
|
|
|
|
| |
The previous refactorings in H.I.Create introduced a few bugs. Filtering
of some types of declarations that we don't handle was removed. This patch
fixes this.
|
| |
|
| |
|
|
|
|
|
|
| |
Output a warning when filtering out data/type instances and associated types
in instances. We don't show these in the documentation yet, and we need to
let the user know.
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
We previously had some code to compute all locally defined names in
a module including subordinate names. We don't need it since we can
get the names from modInfoTyThings in the GHC API.
|