On 17/06/2011, at 12:03 AM, Simon Peyton-Jones wrote:
> Manuel
>
> I got this when validating.
>
> I said “sh validate --no-clean”; some more compiling happened, then the same
> result.
>
> I said “sh validate --no-clean” again, and this time it went through.
>
> Is this the same missing-dependency thing? Did you validate?
>
> Simon
>
> GHC error in desugarer lookup in dph-par:Data.Array.Parallel.Prelude.Bool:
> attempting to use module `dph-par:Data.Array.Parallel.Prelude.Base.Tuple'
> (libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Tuple.hs)
> which is not loaded
> haddock: panic! (the 'impossible' happened)
> (GHC version 7.1.20110204 for x86_64-unknown-linux):
> initDs IOEnv failure
I think this is another symptom of the build race and/or a separate race
exposed by the recent changes.
It appears to happen when:
1) Haddock tries to process dph-common:Data.Array.Parallel.Prelude.Bool
2) That module contains {-# OPTIONS_GHC -fvectorise #-}, so it runs the
vectoriser.
3) The vectoriser produces code that uses tup2 from
dph-common:D.A.P.Prelude.Base.Tuple,
but aren't any direct imports of that module from
dph-common:D.A.P.Prelude.Bool.
4) The type checker tries to demand-load D.A.P.Prelude.Base.Tuple, but as that
module
is also in dph-common, LoadIface.findAndReadIface thinks it should have
already
been loaded so emits the error.
If that reasoning was correct, then I don't know why it wouldn't _always_ die.
However, I'm testing a patch that makes the vectoriser always manually load
D.A.P.Prelude.Base.Tuple, so we'll see if that helps.
Sadly, validate won't always catch build races. :-(
Ben.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
