
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: 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)

Don't know if that helps in tracking the problem, but I have a build from 81f4cd3e08996d35b3a70dfee4d70a829f2f2622 (24 hours ago) and these tests also fail (haddock.base causes framework failure). Janek

On 18/01/13 11:53, Simon Marlow wrote:
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)
More on this: the cabal failures appeared with these two commits:
commit 91b44bc51ab0c7f208e429a4ad0e34541c25ba3b
Author: Simon Peyton Jones

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
I've fixed rnfail055, T4201 (my fault sorry).
haddock.base is ok for me.
Simon
| -----Original Message-----
| From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@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: 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

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@haskell.org [mailto:ghc-devs-bounces@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:
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

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:marlowsd@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-bounces@haskell.org
| > | [mailto:ghc-devs-bounces@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: 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
| >

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@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-bounces@haskell.org | > | [mailto:ghc-devs-bounces@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:
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 | >

| > 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? That would be good. It's here; applyPackageFlag dflags unusable pkgs flag = case flag of ExposePackage str -> case selectPackages (matchingStr str) pkgs unusable of Left ps -> packageFlagErr dflags flag ps Right (p:ps,qs) -> return (p':ps') where p' = p {exposed=True} ps' = hideAll (pkgName (sourcePackageId p)) (ps++qs) _ -> panic "applyPackageFlag" etc The call to packageFlagErr is divergent, of course, but dflags has an error thunk for the pkgState. Simon

On 18/01/13 16:45, Simon Peyton-Jones wrote:
| > 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?
That would be good. It's here;
applyPackageFlag dflags unusable pkgs flag = case flag of ExposePackage str -> case selectPackages (matchingStr str) pkgs unusable of Left ps -> packageFlagErr dflags flag ps Right (p:ps,qs) -> return (p':ps') where p' = p {exposed=True} ps' = hideAll (pkgName (sourcePackageId p)) (ps++qs) _ -> panic "applyPackageFlag"
etc
The call to packageFlagErr is divergent, of course, but dflags has an error thunk for the pkgState.
Looks like we should be using throwIO. Unfortunately I'm out of time right now, feel free to fix it, otherwise I'll do it next week. Cheers, Simon

On Fri, Jan 18, 2013 at 05:03:26PM +0000, Simon Marlow wrote:
On 18/01/13 16:45, Simon Peyton-Jones wrote:
| > 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?
That would be good. It's here;
applyPackageFlag dflags unusable pkgs flag = case flag of ExposePackage str -> case selectPackages (matchingStr str) pkgs unusable of Left ps -> packageFlagErr dflags flag ps Right (p:ps,qs) -> return (p':ps') where p' = p {exposed=True} ps' = hideAll (pkgName (sourcePackageId p)) (ps++qs) _ -> panic "applyPackageFlag"
etc
The call to packageFlagErr is divergent, of course, but dflags has an error thunk for the pkgState.
Looks like we should be using throwIO. Unfortunately I'm out of time right now, feel free to fix it, otherwise I'll do it next week.
I tried that, but it didn't fix it. However, it seems like a sensible thing to be doing anyway, so I pushed the patch. I'll do a sweep for other places that we could/should be using throwIO. Thanks Ian

On 30/01/13 01:20, Ian Lynagh wrote:
On Fri, Jan 18, 2013 at 05:03:26PM +0000, Simon Marlow wrote:
On 18/01/13 16:45, Simon Peyton-Jones wrote:
| > 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?
That would be good. It's here;
applyPackageFlag dflags unusable pkgs flag = case flag of ExposePackage str -> case selectPackages (matchingStr str) pkgs unusable of Left ps -> packageFlagErr dflags flag ps Right (p:ps,qs) -> return (p':ps') where p' = p {exposed=True} ps' = hideAll (pkgName (sourcePackageId p)) (ps++qs) _ -> panic "applyPackageFlag"
etc
The call to packageFlagErr is divergent, of course, but dflags has an error thunk for the pkgState.
Looks like we should be using throwIO. Unfortunately I'm out of time right now, feel free to fix it, otherwise I'll do it next week.
I tried that, but it didn't fix it.
Me too :)
However, it seems like a sensible thing to be doing anyway, so I pushed the patch. I'll do a sweep for other places that we could/should be using throwIO.
Yes, we should definitely be using throwIO. In fact, every use of throwGhcException should be treated with suspicion. Cheers, Simon
participants (4)
-
Ian Lynagh
-
Jan Stolarek
-
Simon Marlow
-
Simon Peyton-Jones