Today's validate failures
Simon Marlow
marlowsd at gmail.com
Fri Jan 18 17:42:08 CET 2013
On 18/01/13 16:18, Simon Peyton-Jones wrote:
> 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!
Right, I agree with that.
> 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.
Whereabouts are we evaluating it? Could we fix that instead?
Cheers,
Simon
> 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:marlowsd at gmail.com]
> | Sent: 18 January 2013 15:09
> | To: Simon Peyton-Jones
> | Cc: ghc-devs at 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-bounces at haskell.org
> | > | [mailto:ghc-devs-bounces at haskell.org]
> | > | On Behalf Of Simon Marlow
> | > | Sent: 18 January 2013 11:54
> | > | To: ghc-devs at 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 at haskell.org
> | > | http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
>
More information about the ghc-devs
mailing list