HEAD build fails on compiling haddoc

Karel Gardas karel.gardas at centrum.cz
Tue Jul 15 12:19:15 UTC 2014


I'm trying to compile HEAD on amd64-solaris2 platform, but the build 
fails with:

"inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -fPIC 
-dynamic  -H32m -O    -hide-all-packages -i -iutils/haddock/driver 
-iutils/haddock/haddock-library/src -iutils/haddock/dist/build 
-iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build 
-Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include 
-optPutils/haddock/dist/build/autogen/cabal_macros.h -package 
Cabal- -package array- -package base- -package 
bytestring- -package containers- -package deepseq- 
-package directory- -package filepath- -package 
ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall 
-fwarn-tabs -O2 -XHaskell2010  -no-user-package-db -rtsopts      -odir 
utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir 
utils/haddock/dist/build   -c utils/haddock/src/Haddock/GhcUtils.hs -o 

     Not in scope: data constructor ‘TyFamInstEqn’
     Perhaps you meant ‘TyFamInstD’ (imported from GHC)

     ‘tfie_rhs’ is not a (visible) constructor field name
gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
gmake: *** [all] Error 2

is this just issue on my system or general issue which waits for someone 
to resolve it?

Since I built HEAD successfully just two days ago, this patch may looks 

commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Tue Jul 15 07:43:55 2014 +0100

     Entirely re-jig the handling of default type-family instances 
(fixes Trac #9063)

     In looking at Trac #9063 I decided to re-design the default
     instances for associated type synonyms.  Previously it was all
     jolly complicated, to support generality that no one wanted, and
     was arguably undesirable.


     * The default instance for an associated type can have only
       type variables on the LHS.  (Not type patterns.)

     * There can be at most one default instances declaration for
       each associated type.

     To achieve this I had to do a surprisingly large amount of refactoring
     of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
     of the LHS patterns.

     That change in HsDecls has a (trivial) knock-on effect in Haddock, so
     this commit does a submodule update too.

     The net result is good though.  The code is simpler; the language
     specification is simpler.  Happy days.

     Trac #9263 and #9264 are thereby fixed as well.

but I'm not expert so no offense! And if this is a mistake on my side, 
then I'm really sorry for false alarm.


More information about the ghc-devs mailing list