HEAD build fails on compiling haddoc

[Karel Gardas]

Yes, I did both `get' and `pull' as it was really (months) old repo. 
Anyway, let's see if builders catch this over night. If not, it was just 
my poor error for which I apologize.

Thanks,
Karel

On 07/15/14 02:28 PM, Simon Peyton Jones wrote:
> 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.
>
> Simon
>
> | -----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
> |
> |
> | Hello,
> |
> | 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/src
> | -iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0
> | -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-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package
> | bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-
> | 1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -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
> | utils/haddock/dist/build/Haddock/GhcUtils.dyn_o
> |
> | utils/haddock/src/Haddock/GhcUtils.hs:105:21:
> |      Not in scope: data constructor 'TyFamInstEqn'
> |      Perhaps you meant 'TyFamInstD' (imported from GHC)
> |
> | utils/haddock/src/Haddock/GhcUtils.hs:105:36:
> |      '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
> | suspiciously:
> |
> | 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.
> |
> |      Specifically
> |
> |      * 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.
> |
> | Thanks!
> | Karel
>