OK I've got it.
Consider this:
f :: ((Int,Int) -> String) -> (Int,Int) -> a
f g pr = error (g pr)
main = print (f fst (1, error "no"))
Does this print "1" or "no"?
Well f diverges and so is hyperstrict. So it's ok to evaluate as much of the
argument as you like!
In Packages we have a dflags with an error thunk in it for pkgState, and it's
the strict evaluation of that pkgState that is changing the behaviour.
Well in fact I can change it so that this won't happen, and I will do so, but
it it's not actually wrong.
Simon
| -----Original Message-----
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 18 January 2013 15:09
| To: Simon Peyton-Jones
| Cc: ghc-devs@haskell.org
| Subject: Re: Today's validate failures
|
| On 18/01/13 14:50, Simon Peyton-Jones wrote:
| > I have no idea what the cabal ones are. They report
| > +ghc-stage2: panic! (the 'impossible' happened)
| > + (GHC version 7.7 for x86_64-unknown-linux):
| > + no package state yet: call GHC.setSessionDynFlags
|
| This happens when something touches pkgState in defaultDynFlags:
|
| pkgState = panic "no package state yet: call
| GHC.setSessionDynFlags",
|
| Could it be that the new demand analyser has made something too strict?
|
| Cheers,
| Simon
|
|
|
| > I've fixed rnfail055, T4201 (my fault sorry).
| >
| > haddock.base is ok for me.
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: ghc-devs-boun...@haskell.org
| > | [mailto:ghc-devs-boun...@haskell.org]
| > | On Behalf Of Simon Marlow
| > | Sent: 18 January 2013 11:54
| > | To: ghc-devs@haskell.org
| > | Subject: Today's validate failures
| > |
| > | I have several validate failures today:
| > |
| > | Unexpected failures:
| > | cabal 1750 [bad stderr] (normal)
| > | cabal shadow [bad stderr]
| (normal)
| > | perf/haddock haddock.base [stat not good
| > | enough] (normal)
| > | rename/should_fail rnfail055 [stderr mismatch]
| > | (normal)
| > | simplCore/should_compile T4201 [bad stdout] (normal)
| > |
| > | The cabal ones are mysterious, but I definitely didn't see them
| > | yesterday, and I'm certain they're not caused by anything I've done.
| > | The only patch in my tree is one that puts back the vector/primitive
| > | submodules that I accidentally deleted.
| > |
| > |
| > | Actual stderr output differs from expected:
| > | --- ./rename/should_fail/rnfail055.stderr 2013-01-07
| 08:47:29.856696930
| > | +0000
| > | +++ ./rename/should_fail/rnfail055.comp.stderr 2013-01-18
| > | 09:59:24.531420493 +0000
| > | @@ -52,6 +52,19 @@
| > | RnFail055.hs-boot:17:12:
| > | T3' is exported by the hs-boot file, but not exported by the
| > | module
| > |
| > | +RnFail055.hs-boot:19:6:
| > | + Type constructor `T4' has conflicting definitions in the module
| > | +and
| > | its hs-boot file
| > | + Main module: data T4 a
| > | + No C type associated
| > | + RecFlag Recursive
| > | + = T4 :: forall a. (forall b. a -> b) -> T4 a
| > | Stricts: _
| > | + FamilyInstance: none
| > | + Boot file: data T4 b
| > | + No C type associated
| > | + RecFlag NonRecursive
| > | + = T4 :: forall b. (forall a. b -> a) -> T4 b
| > | Stricts: _
| > | + FamilyInstance: none
| > | +
| > | RnFail055.hs-boot:21:6:
| > | Type constructor `T5' has conflicting definitions in the
| > | module and its hs-boot file
| > | Main module: data T5 a
| > | *** unexpected failure for rnfail055(normal)
| > |
| > | Actual stdout output differs from expected:
| > | --- ./simplCore/should_compile/T4201.stdout 2013-01-07
| > | 08:47:29.856696930 +0000
| > | +++ ./simplCore/should_compile/T4201.run.stdout 2013-01-18
| > | 09:57:59.015418374 +0000
| > | @@ -1,3 +1,3 @@
| > | - Unfolding: (Eta.bof
| > | - `cast`
| > | - (Sym (Eta.NTCo:Foo[0]) -> Refl Eta.T)) -}
| > | + {- Arity: 1, HasNoCafRefs, Strictness: <S,U>m,
| > | + Unfolding: InlineRule (0, True, True)
| > | + Eta.bof `cast` (Sym (Eta.NTCo:Foo[0]) -> Refl
| > | + Eta.T) -}
| > | *** unexpected failure for T4201(normal)
| > |
| > |
| > |
| > | Actual stderr output differs from expected:
| > | --- ./rename/should_fail/rnfail055.stderr 2013-01-07
| 08:47:29.856696930
| > | +0000
| > | +++ ./rename/should_fail/rnfail055.comp.stderr 2013-01-18
| > | 09:59:24.531420493 +0000
| > | @@ -52,6 +52,19 @@
| > | RnFail055.hs-boot:17:12:
| > | T3' is exported by the hs-boot file, but not exported by the
| > | module
| > |
| > | +RnFail055.hs-boot:19:6:
| > | + Type constructor `T4' has conflicting definitions in the module
| > | +and
| > | its hs-boot file
| > | + Main module: data T4 a
| > | + No C type associated
| > | + RecFlag Recursive
| > | + = T4 :: forall a. (forall b. a -> b) -> T4 a
| > | Stricts: _
| > | + FamilyInstance: none
| > | + Boot file: data T4 b
| > | + No C type associated
| > | + RecFlag NonRecursive
| > | + = T4 :: forall b. (forall a. b -> a) -> T4 b
| > | Stricts: _
| > | + FamilyInstance: none
| > | +
| > | RnFail055.hs-boot:21:6:
| > | Type constructor `T5' has conflicting definitions in the
| > | module and its hs-boot file
| > | Main module: data T5 a
| > | *** unexpected failure for rnfail055(normal)
| > |
| > | _______________________________________________
| > | ghc-devs mailing list
| > | ghc-devs@haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-devs
| >
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
