- ghc-tickets - Haskell.org

Re: [GHC] #5591: Type constructor variables not injective
by GHC 04 Apr '13

04 Apr '13

#5591: Type constructor variables not injective ---------------------------------------------------------+------------------ Reporter: daniel.is.fischer | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.2.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: indexed-ypes/should_compile/T5591a, T5591b | Blockedby: Blocking: | Related: ---------------------------------------------------------+------------------ Changes (by morabbin): * cc: andy.adamsmoran@… (added) Comment: Is this related to #6018? Brent's [http://stackoverflow.com/questions/7866375/why-does-ghc-think-that-this- type-variable-is-not-injective/ stack overflow] comment seems to imply it is. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5591#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4259: Relax restrictions on type family instance overlap
by GHC 04 Apr '13

04 Apr '13

#4259: Relax restrictions on type family instance overlap ----------------------------------------+----------------------------------- Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Changes (by morabbin): * cc: andy.adamsmoran@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4259#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7798: test_bindist reports ".../libffi-6.dll (No such file or directory)"
by GHC 04 Apr '13

04 Apr '13

#7798: test_bindist reports ".../libffi-6.dll (No such file or directory)" -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Since http://darcs.haskell.org/ghcBuilder/builders/tn23/873.html, the tn23 builder {{{ $ uname -a Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ }}} has failed with (http://darcs.haskell.org/ghcBuilder/builders/tn23/876/16.html) {{{ ranlib: file: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.7.20130328/rts-1.0/libCffi_thr_p.a(ffi64.o) has no symbols install: rts/dist/build/libCffi_debug-ghc7.7.20130328.dylib: No such file or directory install: rts/dist/build/libCffi_thr-ghc7.7.20130328.dylib: No such file or directory install: rts/dist/build/libCffi_thr_debug-ghc7.7.20130328.dylib: No such file or directory install: rts/dist/build/libCffi_l-ghc7.7.20130328.dylib: No such file or directory install: rts/dist/build/libCffi_thr_l-ghc7.7.20130328.dylib: No such file or directory install: rts/dist/build/libffi-6.dll: No such file or directory strip: can't open file: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.7.20130328/rts-1.0/libffi-6.dll (No such file or directory) make[3]: *** [install_packages] Error 1 make[2]: *** [install] Error 2 make[1]: *** [test_bindist] Error 2 make: *** [test_bindist] Error 2 }}} The am-deb7-64 builder seems to have a similar problem (http://darcs.haskell.org/ghcBuilder/builders/am-deb7-64/356/16.html) Best regards Thorkil -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #6018: Injective type families
by GHC 04 Apr '13

04 Apr '13

#6018: Injective type families ----------------------------------------+----------------------------------- Reporter: lunaris | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: TypeFamilies, Injective | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4259 | ----------------------------------------+----------------------------------- Changes (by morabbin): * cc: andy.adamsmoran@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6018#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7589: LLVM 3.2 Support
by GHC 03 Apr '13

03 Apr '13

#7589: LLVM 3.2 Support -----------------------------+---------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- LLVM 3.2 is out as of mid December. We need to update the backend to support it. There seems to be a number of new bugs due to the change. With LLVM 3.1 we get the following testsuite failures: {{{ OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013 3552 total tests, which gave rise to 13164 test cases, of which 0 caused framework failures 11606 were skipped 1515 expected passes 23 had missing libraries 15 expected failures 0 unexpected passes 5 unexpected failures Unexpected failures: * codeGen/should_run cgrun044 [exit code non-0] (optllvm) * concurrent/should_run 367_letnoescape [bad exit code] (optllvm) * numeric/should_run arith005 [bad stdout] (optllvm) typecheck/should_compile tc226 [exit code non-0] (optllvm) typecheck/should_compile tc235 [exit code non-0] (optllvm) }}} Where the failures marked with '*' are unique to the LLVM backend. With LLVM 3.2 we get the following: {{{ OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013 3552 total tests, which gave rise to 13164 test cases, of which 0 caused framework failures 11606 were skipped 1512 expected passes 23 had missing libraries 15 expected failures 0 unexpected passes 8 unexpected failures Unexpected failures: ** codeGen/should_compile 1916 [exit code non-0] (optllvm) ** codeGen/should_run cgrun028 [exit code non-0] (optllvm) * codeGen/should_run cgrun044 [exit code non-0] (optllvm) * concurrent/should_run 367_letnoescape [bad exit code] (optllvm) * numeric/should_run arith005 [bad stdout] (optllvm) ** numeric/should_run numrun012 [exit code non-0] (optllvm) typecheck/should_compile tc226 [exit code non-0] (optllvm) typecheck/should_compile tc235 [exit code non-0] (optllvm) }}} Where failures marked with '*' are unique to the LLVM backend and failures marked with '**' are unique to LLVM 3.2 relative to 3.1. I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -> 3.2. I'll create a separate ticket for that. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #7805: Panic: promoteType with higher-rank datatype
by GHC 03 Apr '13

03 Apr '13

#7805: Panic: promoteType with higher-rank datatype -------------------------------+-------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: DataKinds Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- The following code causes the panic in HEAD: {{{ {-# LANGUAGE DataKinds, RankNTypes, TypeFamilies #-} data HigherRank = HR (forall a. a -> a) type family F (x :: HigherRank) type instance F (HR x) = Bool }}} Here is the panic text: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130329 for x86_64-apple-darwin): promoteType }}} This panic does not happen with GHC 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7804: Ambiguity check too eager in presence of RankNTypes and TypeFamilies
by GHC 03 Apr '13

03 Apr '13

#7804: Ambiguity check too eager in presence of RankNTypes and TypeFamilies --------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: AmbiguityCheck Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code compiles in 7.6.1 but not in 7.7: {{{ {-# LANGUAGE TypeFamilies, RankNTypes #-} type family F f a type family G f data Proxy a = P sDFMap :: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) sDFMap _ = P }}} Here is the error message: {{{ Couldn't match type `G f0' with `G f' NB: `G' is a type function, and may not be injective The type variable `f0' is ambiguous Expected type: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) Actual type: (forall a. Proxy f0 -> Proxy a -> Proxy (F f0 a)) -> Proxy (G f0) In the ambiguity check for: forall f. (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) In the type signature for `sDFMap': sDFMap :: (forall a. Proxy f -> Proxy a -> Proxy (F f a)) -> Proxy (G f) }}} It is true that {{{sDFMap}}} is ''sometimes'' ambiguous, but it is not ''always'' ambiguous. For example, if we have {{{ foo :: Proxy Bool -> Proxy a -> Proxy (F Bool a) foo _ _ = P bar = sDFMap foo }}} the call to {{{sDFMap}}} is well defined, with {{{f ~ Bool}}}. If the type signature for {{{foo}}} did not specify the value of {{{f}}}, the call to {{{sDFMap}}} would indeed be ambiguous and should be rejected. GHC 7.6.1 does catch the error when the type of {{{foo}}} uses a variable instead of {{{Bool}}}. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7176: Failure to let kind variable remain uninstantiated when not needed
by GHC 03 Apr '13

03 Apr '13

#7176: Failure to let kind variable remain uninstantiated when not needed -------------------------------+-------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: PolyKinds TypeFamilies Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: polykinds/T7176 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj@…): commit 1128f1e02ff06fee89b62fb756ac0c28edcf4625 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Apr 3 14:37:50 2013 +0100 This changes fixes a bad error in canonicalisation, concerning kind equality We care careful not to construct a canonical equality whose LHS and RHS have incompatible kinds. (This is one of the invariants of a canonical equality.) See Note [Equalities with incompatible kinds]. However, what I had not dealt with is when LHS and RHS *look* as if they have different kinds, but after zonking they become the same. Bad! (This led to an ASSERT failure in the test for Trac #7176.) compiler/typecheck/TcCanonical.lhs | 111 +++++++++++++++++++++--------------- 1 files changed, 65 insertions(+), 46 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7176#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 03 Apr '13

03 Apr '13

#427: Random.StdGen slowness --------------------------------------+------------------------------------- Reporter: remit | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by joell): This ticket seems to be almost describing two separate issues: the performance of the random package and the "thunk-bomb" problem in `getStdRandom`. While I admit I haven't looked into the performance aspect, I am now well acquainted with the "thunk-bomb" aspect. Turns out a metrics library we were using at my company made a `randomRIO` call that in some cases (all of them in our configuration) wouldn't actually use the generated random value. This led to me spending a few days trying to figure out why our services were consuming and retaining gigabytes of memory. (For those interested in case studies, the discussion with the metrics library folks is here: https://github.com/brendanhay/network-metrics/issues/4 .) So I would like to petition that the change Remi suggested in comment:17 to make `getStdRandom` strict (or something along those lines) be made. To my mind (heavily biased by the experience of the last few days), I wouldn't really consider the "thunk-bomb" aspect a performance problem so much as a stability one. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/427#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 03 Apr '13

03 Apr '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: simplCore/should_compile/T5550 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => simplCore/should_compile/T5550 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0