HEAD build fails on compiling haddoc
Simon Peyton Jones
simonpj at microsoft.com
Tue Jul 15 12:28:17 UTC 2014
I pushed a change to Haddock, and a change to GHC. They should match up. Did you do ./sync-all pull?
I may have screwed up. I sent a long message to ghc-devs this morning explaining what I did. Maybe some guru can help.
| -----Original Message-----
| From: Karel Gardas [mailto:karel.gardas at centrum.cz]
| Sent: 15 July 2014 13:19
| To: ghc-devs; Simon Peyton Jones
| Subject: HEAD build fails on compiling haddoc
| 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-18.104.22.168 -package array-0.5.0.0 -package base-22.214.171.124 -package
| bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-
| 126.96.36.199 -package directory-188.8.131.52 -package filepath-184.108.40.206 -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: *** [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
| of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the
| of the LHS patterns.
| That change in HsDecls has a (trivial) knock-on effect in Haddock,
| 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