- ghc-tickets - Haskell.org

[GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory]
by GHC 09 Nov '14

09 Nov '14

#9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: smartos illumos | Operating System: Solaris lndir sdist | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- It appears that source for lndir was intentionally included in utils and customized to handle .git directories: http://git.haskell.org/ghc.git/blobdiff/c629bd1539b1865cc28ce053234595e7aeb… This ignoring of .git directories has been in the upstream lndir.c since 2009: http://cgit.freedesktop.org/xorg/util/lndir/tree/lndir.c However, lndir is not installed by default (on Ubuntu or SmartOS) and is not listed in the tools required to build: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools It does not appear to be built during the sync, boot, or make steps of a GHC build. Here is an excerpt: {{{ /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] ghc.mk:1117: recipe for target 'sdist-ghc-prep' failed gmake[1]: *** [sdist-ghc-prep] Error 127 Makefile:64: recipe for target 'sdist' failed gmake: *** [sdist] Error 2 }}} Here is a detailed log: http://haskell.inf.elte.hu/builders/smartos-x86_64-head/19/16.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9785: Link error when using Data.Vector in separate compilation mode
by GHC 09 Nov '14

09 Nov '14

#9785: Link error when using Data.Vector in separate compilation mode -------------------------------------+------------------------------------- Reporter: yugr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I compile attached files all at once they link fine: $ ghc A.hs B.hs Main.hs Linking Main.exe ... But with separate compilation they produce link errors: $ rm -f *.o *.hi $ ghc -c A.hs $ ghc -c B.hs $ ghc -c Main.hs $ ghc A.o B.o Main.o B.o:fake:(.text+0x34): undefined reference to `vectorzm0zi10zi11zi0_DataziVector_fromList_closure' B.o:fake:(.data+0x20): undefined reference to `vectorzm0zi10zi11zi0_DataziVector_fromList_closure' c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: B.o: bad reloc address 0x20 in section `.data' c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation collect2: ld returned 1 exit status I'm using the latest Haskell Platform 2014.2.0.0 for Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7862: Could not deduce (A) from the context (A, ...)
by GHC 09 Nov '14

09 Nov '14

#7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by spacekitteh): * version: 7.6.2 => 7.8.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7862#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7862: Could not deduce (A) from the context (A, ...)
by GHC 09 Nov '14

09 Nov '14

#7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Another example of this bug: {{{ {-# LANGUAGE AllowAmbiguousTypes, DefaultSignatures, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, UndecidableInstances, PolyKinds, ConstraintKinds, InstanceSigs, TypeFamilies #-} module Control.SmallCategory where import GHC.Exts import Control.Category class Vacuous (a:: i) instance Vacuous a class SmallCategory cat where type Objects cat :: i -> Constraint type Objects cat = Vacuous type Morphisms cat :: a -> a -> b id :: (Objects cat a) => (Morphisms cat) a a (.) :: (Objects cat a, Objects cat b, Objects cat c) => (Morphisms cat) b c -> (Morphisms cat) a b -> (Morphisms cat) a c instance (Category c, Category (Morphisms c)) => SmallCategory c where type Objects c = Vacuous type (Morphisms c) = c id = Control.Category.id (.) = (Control.Category..) src/Control/SmallCategory.hs:34:10: Could not deduce (Category (Morphisms c)) arising from a use of ‘Control.Category.id’ from the context (Category c, Category (Morphisms c)) bound by the instance declaration at src/Control/SmallCategory.hs:31:10-64 or from (Objects c a) bound by the type signature for id :: (Objects c a) => Morphisms c a a at src/Control/SmallCategory.hs:34:5-6 In the expression: Control.Category.id In an equation for ‘id’: id = Control.Category.id In the instance declaration for ‘SmallCategory c’ src/Control/SmallCategory.hs:35:11: Could not deduce (Category (Morphisms c)) arising from a use of ‘Control.Category..’ from the context (Category c, Category (Morphisms c)) bound by the instance declaration at src/Control/SmallCategory.hs:31:10-64 or from (Objects c a, Objects c b, Objects c c1) bound by the type signature for (.) :: (Objects c a, Objects c b, Objects c c1) => Morphisms c b c1 -> Morphisms c a b -> Morphisms c a c1 at src/Control/SmallCategory.hs:35:5-7 In the expression: (Control.Category..) In an equation for ‘.’: (.) = (Control.Category..) In the instance declaration for ‘SmallCategory c’ }}} in 7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7862#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended
by GHC 09 Nov '14

09 Nov '14

#9779: Darin Morrison's brewtap for ghc is deprecated, and should not be recommended -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | Documentation bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- The Building/Preparation/MacOSX page suggests using Darin Morrison's brewtap to install ghc using Homebrew: 3. Use one of Fink, MacPorts or Brew. If using brew, we strongly recommend using Darin's brewtap for ghc Darin's brewtap, however, is deprecated: https://github.com/darinmorrison/homebrew-haskell For the most part, it seems that the default homebrew install works correctly, but `./configure` fails because Happy is not installed. We should either (1) remove the recommendation to use Homebrew or (2) explain how to install all of the necessary components to build GHC. (I couldn't figure out how to install Happy using Homebrew's cabal-install formula, so I used the GHC Platform instead.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8699: Multiple test faliures on 32-bit Linux systems.
by GHC 08 Nov '14

08 Nov '14

#8699: Multiple test faliures on 32-bit Linux systems. ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I ran validate with HEAD (e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19) on 3 different 32-bit Linux boxes and I'm seeing different failures on each one. I was advised on IRC to create a ticket with all the failures. The first and third box are using the binary of 7.6.3 provided on the GHC site. I had to link libgmp.so.3 to libgmp.so.10 on both of these in order to get it to install properly. Please ask about any info that I have not provided below! First box: {{{Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.0 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.0, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 16 Oct 14 04:24 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 lrwxrwxrwx 1 root root 12 May 31 2013 /usr/lib/libgmp.so.3 -> libgmp.so.10 }}} The full log is at [1]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.base" OVERALL SUMMARY for test run started at Sun Jan 26 03:26:36 2014 GMT 0:19:58 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3458 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} As discussed on the mailing list, the Haddock numbers still need tweaking even after Austin updated them the other day. T1969 failure seems to come and go. ---- Second box: {{{Linux yuuki 3.11.4-gentoo #1 SMP Tue Oct 8 00:19:37 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} I installed the bootstrapping compiler on this box from Gentoo's package manager so I'm not sure how gmp is linked here. I can retry by boostrapping from binary and linking libgmp.3 to libgmp.10 (like the other boxes did) for consistency. The version of this complier is 7.6.3-r1. The full log is at [2]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.compiler T7859" OVERALL SUMMARY for test run started at Sun Jan 26 03:34:47 2014 GMT 0:12:04 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3453 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} A different Haddock perf failure, T1969 seems to have failed again and a totally new failure, T7859. ---- Third box: {{{Linux lenalee 3.11.4-gentoo #1 SMP Mon Oct 7 19:19:00 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 9 Jan 26 02:42 /usr/lib/libgmp.so.3 -> libgmp.so lrwxrwxrwx 1 root root 16 Nov 20 11:54 /usr/lib/libgmp.so -> libgmp.so.10.1.3 }}} The full log is at [3]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="hsc2hs004 T3837 haddock.compiler haddock.base T3307 environment001 T1969 gadt23 Capi_Ctype_001 Capi_Ctype_002" OVERALL SUMMARY for test run started at Sun Jan 26 03:28:47 2014 GMT 0:10:37 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3446 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ../../libraries/base/tests/IO T3307 [bad stderr] (normal) ../../libraries/base/tests/IO environment001 [bad stderr] (normal) ffi/should_run Capi_Ctype_001 [bad stderr] (normal) ffi/should_run Capi_Ctype_002 [bad stderr] (normal) gadt gadt23 [bad stderr] (normal) hsc2hs T3837 [bad stderr] (normal) hsc2hs hsc2hs004 [bad stderr] (normal) perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} Whole plethora of failures! Haddock numbers again and a bunch of other stuff. Considering how close 7.8 is, I think these should be looked at (especially that last set doesn't look too good). I notice that over 2000 more tests were skipped on the first box (this is my day-to-day use computer). How are the tests to be skipped determined? [1]: http://fuuzetsu.co.uk/misc/validate-misaki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [2]: http://fuuzetsu.co.uk/misc/validate-yuuki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [3]: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl
by GHC 08 Nov '14

08 Nov '14

#9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE BangPatterns #-} import Data.Vector (Vector, (!)) import qualified Data.Vector as Vec import Data.Ix (Ix) import qualified Data.Ix as Ix vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a vecIndexIx vec ix = vec ! Ix.index (minBound :: ix, maxBound :: ix) ix vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [ y | ix <- Ix.range bounds, let !y = f ix ] where bounds = (minBound, maxBound) }}} The following errors occur: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l cabal cabal.sandbox.config cabal_problem.hs Prelude> :l cabal_problem.hs [1 of 1] Compiling Main ( cabal_problem.hs, interpreted ) cabal_problem.hs:9:37: Could not deduce (Bounded ix1) arising from a use of ‘minBound’ from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: minBound :: ix In the first argument of ‘Ix.index’, namely ‘(minBound :: ix, maxBound :: ix)’ In the second argument of ‘(!)’, namely ‘Ix.index (minBound :: ix, maxBound :: ix) ix’ cabal_problem.hs:9:53: Could not deduce (Bounded ix1) arising from a use of ‘maxBound’ from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: maxBound :: ix In the first argument of ‘Ix.index’, namely ‘(minBound :: ix, maxBound :: ix)’ In the second argument of ‘(!)’, namely ‘Ix.index (minBound :: ix, maxBound :: ix) ix’ cabal_problem.hs:12:32: Could not deduce (Ix a0) arising from a use of ‘Ix.rangeSize’ from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance Ix () -- Defined in ‘GHC.Arr’ instance (Ix a, Ix b) => Ix (a, b) -- Defined in ‘GHC.Arr’ instance (Ix a1, Ix a2, Ix a3) => Ix (a1, a2, a3) -- Defined in ‘GHC.Arr’ ...plus 8 others In the first argument of ‘Vec.fromListN’, namely ‘(Ix.rangeSize bounds)’ In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] In an equation for ‘vecCreateIx’: vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] where bounds = (minBound, maxBound) cabal_problem.hs:12:45: Could not deduce (Bounded a0) arising from a use of ‘bounds’ from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance Bounded Data.Monoid.All -- Defined in ‘Data.Monoid’ instance Bounded Data.Monoid.Any -- Defined in ‘Data.Monoid’ instance Bounded a => Bounded (Data.Monoid.Dual a) -- Defined in ‘Data.Monoid’ ...plus 23 others In the first argument of ‘Ix.rangeSize’, namely ‘bounds’ In the first argument of ‘Vec.fromListN’, namely ‘(Ix.rangeSize bounds)’ In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] Failed, modules loaded: none. }}} The remedy was in this pull request https://github.com/haskell/hackage- server/pull/273/files under the file "Distribution/Server/Features/Search/DocTermIds.hs" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9770: GHC Parser fails on Haddock comment on parameter of a function record field
by GHC 08 Nov '14

08 Nov '14

#9770: GHC Parser fails on Haddock comment on parameter of a function record field -------------------------------------+------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: Haddock | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I tried to document parameter of a function that is a record field. The Haddock fails with parse error on input ‘->’ {{{ data D = D { field :: () -- ^ parameter -> () } }}} Please see https://github.com/haskell/haddock/issues/343 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9714: Un-`wire` Integer type
by GHC 08 Nov '14

08 Nov '14

#9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: Integer | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: #9281 | Blocking: | Differential Revisions: Phab:351 -------------------------------------+------------------------------------- `Integer` is currently a wired-in type for `integer-gmp`. This requires replicating its inner structure in `TysWiredIn.lhs`, which makes it much harder to change `Integer` to a more complex representation (like e.g. for #9281) In order to reduce the redundancy (due to wired-in type mirroring) and simplify the code, as [http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5823/ suggested by Simon], `Integer` should no longer be a `wired-in` type but rather become a `known-key`-entity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable
by GHC 08 Nov '14

08 Nov '14

#9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If GND is enabled, and roles don't permit a `Foldable` instance to be derived, it won't fall back on `DeriveFoldable`; instead it just produces an error. I think ideally I'd want to use a pragma to state explicitly that I want to use `DeriveFoldable`-style deriving for this specific instance, but an implicit fallback would be acceptable. {{{#!hs {-# LANGUAGE -- GeneralizedNewtypeDeriving, DeriveFoldable #-} module Derive where import qualified Data.IntMap as M newtype UniqFM ele = UFM {unUFM :: M.IntMap ele} deriving (Foldable) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7