Fix up Haddock mark-up
New Haddock changes will mean that any previously failing Haddock parses (which resulted in no documentation) will now be parsed. This means that the resulting documentation might not look too great. These need to be human-checked and fixed up if needed.
Here are the failures from recent validate run:
14923:doc comment parse failed: block decorated with fact
14924- @ end dg.tex
14925-Warning: Compiler.Hoopl.Dataflow: Instances of type and data families and equations of closed type families are not yet supported.Instances of the following families will be filtered out:
14926- Fact
14927- 30% ( 10 / 33) in 'Compiler.Hoopl.Dataflow'
17735:doc comment parse failed: plusUFM_CD f m1 d1 m2 d2
17736- merges the maps using `f` as the combinding function and d1 resp. d2 as
17737- the default value if there is no entry in m1 reps. m2. The domain is the union
17738- of the domains of m1 m2.
17739- Representative example:
17740- > plusUFM_CD f {A: 1, B: 2} 23 {B: 3, C: 4} 42
17741- > == {A: f 1 42, B: f 2 3, C: f 23 4 }
17742- 4% ( 2 / 49) in 'UniqFM'
17790:doc comment parse failed: If @co :: T ts ~ rep_ty@ then:
17791-
17792- > instNewTyCon_maybe T ts = Just (rep_ty, co)
17793- Checks for a newtype, and for being saturated
17794- 32% ( 38 /117) in 'Coercion'
17813-haddock module header parse failed: Cannot parse header documentation paragraphs
17814- 75% ( 3 / 4) in 'Llvm.MetaData'
18100:doc comment parse failed: @argTyFold@ implements a generalised and safer variant of the @arg@
18101- function from Figure 3 in <http://dreixel.net/research/pdf/gdmh.pdf>. @arg@
18102- is conceptually equivalent to:
18103-
18104- > arg t = case t of
18105- > _ | isTyVar t -> if (t == argVar) then Par1 else Par0 t
18106- > App f [t'] |
18107- representable1 f &&
18108- t' == argVar -> Rec1 f
18109- > App f [t'] |
18110- representable1 f &&
18111- t' has tyvars -> f :.: (arg t')
18112- > _ -> Rec0 t
18113-
18114- where @argVar@ is the last type variable in the data type declaration we are
18115- finding the representation for.
18116-
18117- @argTyFold@ is more general than @arg@ because it uses 'ArgTyAlg' to
18118- abstract out the concrete invocations of @Par0@, @Rec0@, @Par1@, @Rec1@, and
18119- @:.:@.
18120-
18121- @argTyFold@ is safer than @arg@ because @arg@ would lead to a GHC panic for
18122- some data types. The problematic case is when @t@ is an application of a
18123- non-representable type @f@ to @argVar@: @App f [argVar]@ is caught by the
18124- @_@ pattern, and ends up represented as @Rec0 t@. This type occurs /free/ in
18125- the RHS of the eventual @Rep1@ instance, which is therefore ill-formed. Some
18126- representable1 checks have been relaxed, and others were moved to
18127- @canDoGenerics1@.
18128- 0% ( 0 / 8) in 'TcGenGenerics'
Trac metadata
Trac field | Value |
---|---|
Version | 7.7 |
Type | Task |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |