April 2015 - ghc-tickets

[GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken
by GHC 29 Dec '15

29 Dec '15

#9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- {{{ rwbarton@morphism:~/ghc$ ghc --print-gcc-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Gcc Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rwbarton@morphism:~/ghc$ ghc --print-ld-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Ld Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In 2d2650bf65da3aede4e1c1ca4da623092b869dbe and subsequent commits (between 7.6 and 7.8) these settings fields became "C compiler link flags" and "ld flags". (I think, more or less.) The real problem is that Cabal still looks for the settings fields "Gcc Linker flags" and "Ld Linker flags". I guess this should be updated on the Cabal side though. (They are empty on at least Linux x86_64, which I guess is why nobody noticed before.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI
by GHC 27 Dec '15

27 Dec '15

#9414: GHC 7.8.3 compilation fails on Raspberry PI ----------------------------+--------------------------------------- Reporter: ipuustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------- Tried to compile GHC 7.8.3 from the source package on Raspbian (a Debian- based Raspberry PI distribution). The installed GHC version is 7.4.1. All build dependencies for 7.4.1 were installed ('apt-get build-dep ghc'). {{{ "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll- split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist- install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll- split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user- package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist- install/build -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/filepath/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/rts/dist/build' -optl-lgmp -optl-lm -optl-lrt -optl-ldl -fPIC -dynamic -H32m -O -hide-all- packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist- install/build -Iutils/dll-split/dist-install/build/autogen -optP- include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -fno-use- rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../base-4.7.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer- gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split /dist-install/build/Main.dyn_o "cp" -p utils/dll-split/dist-install/build/tmp/dll-split inplace/lib/bin /dll-split "rm" -f inplace/bin /dll-split echo '#!/bin/bash' >> inplace/bin/dll-split echo 'executablename="/home/pi/ghc/ghc-7.8.3/inplace/lib/bin/dll-split"' >> inplace/bin/dll-split echo 'datadir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'bindir="/home/pi/ghc/ghc-7.8.3/inplace/bin"' >> inplace/bin/dll-split echo 'topdir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'pgmgcc="/usr/bin/gcc"' >> inplace/bin/dll-split echo 'export LD_LIBRARY_PATH="/home/pi/ghc/ghc-7.8.3/libraries/filepath /dist-install/build:/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build:/home/pi/ghc/ghc-7.8.3/rts/dist/build:$LD_LIBRARY_PATH"' >> inplace/bin/dll-split echo 'exec "$executablename" ${1+"$@"}' >> inplace/bin /dll-split chmod +x inplace/bin /dll-split inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Keskeytetty make: *** [all] Virhe 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9176: GHC not generating dyn_hi files
by GHC 26 Dec '15

26 Dec '15

#9176: GHC not generating dyn_hi files ----------------------------------+---------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: dynamic | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot
by GHC 25 Dec '15

25 Dec '15

#9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that {{{ Myfile.hs:1:1: cannot find normal object file 'Othe.dyn_o` while linking an interpreted expression }}} So `Other` was wrongly made into `Othe`, dropping the last character. If I don't pass `-osuf .something`, or have it not have a dot, everything's fine. The trouble is that `-osuf .something` worked fine in GHC <= 7.6. So I believe this is a regression, or at least a very bad error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9975: RecordWildCards and PatternSynonyms cause impossible bug
by GHC 24 Dec '15

24 Dec '15

#9975: RecordWildCards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X RecordWildCards PatternSynonyms | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using RecordWildCards with PatternSynonyms, I have found a way to cause this bug: $ /usr/local/bin/ghc-7.10.0.20141222 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): find_tycon Test [Test defined at test.hs:6:9, Test parent:Test defined at test.hs:4:13] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here is the full code that causes it: {{{#!hs {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE PatternSynonyms #-} data Test = Test { x :: Int } pattern Test wat = Test { x = wat } }}} If you remove RecordWildCards, the bug does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9739: GHC 7.8 chokes on recursive classes
by GHC 23 Dec '15

23 Dec '15

#9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Type checking this makes GHC 7.8.3 loop: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Foo where class Class3 a => Class1 a where class Class2 t a where class2 :: (Class3 t) => a -> m class (Class1 t, Class2 t t) => Class3 t where }}} Does not happen in 7.6.3. I think it's something to do with the `Class3` constraint appearing in `class2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument
by GHC 21 Dec '15

21 Dec '15

#10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: None/Unknown libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Is there any reason why `Const` isn't kind polymorphic? {{{#!hs newtype Const a (b :: k) = Const { getConst :: a } deriving (Generic, Generic1) }}} An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} import Control.Applicative data Ty = TyBool | TyArr Ty Ty data PTerm :: (Ty -> *) -> Ty -> * where Var :: v t -> PTerm v t Tru :: PTerm v 'TyBool Fals :: PTerm v 'TyBool App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) newtype Term t = Term (forall v. PTerm v t) showT :: Term t -> String showT (Term pterm) = show' 'a' pterm where show' :: Char -> PTerm (Const Char) t -> String show' _ (Var (Const c)) = [c] show' _ Tru = "True" show' _ Fals = "False" show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) }}} but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and the compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform
by GHC 20 Dec '15

20 Dec '15

#10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, ghc-prim is using GCC's {{{__builtin_ctz(ll)/clz(ll)}}} functions to implement functionality to count leading or trailing zeros in provided integer type variable. The problem with those GCC's builtins is that on platform which does not implement either of the operation in ISA, such function call can't be replaced by simple ISN, but needs to be replaced by the call to the libgcc library which then implements the missing operation in generic C. In ghc- prim you can already see a workaround for missing *ll functions on i386. The problem is that generic SPARC (v9) does not provide ISNs in its ISA to implement those builtins effectively so any call to builtins above is replaced by the call to the libgcc. The inserted functions calls are {{{__ctzsi2/__ctzdi2/__clzsi2/__clzdi2}}} in this case. Unfortunately this makes a lot of GHCi testcases (if not all!) failing with the error: {{{ ghc-stage2: /home/karel/src/obj-ghc-sparc-reg_ncg- head-2015-04-07-debug/libraries/ghc-prim/dist-install/build/HSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.o: unknown symbol `__clzdi2' ghc-stage2: unable to load package `ghc-prim-0.4.0.0' }}} Please note, this happens only on platforms which does not support shared libs for GHC. On platforms with GHC shared libs support, ghc-prim is shared library which is correctly linked against the libgcc shared library and such error does not happen. (example Solaris/i386). Unfortunately we can't link ghc-prim*.o with libgcc -- it does effectively nothing so there are two solution for this issue IMHO: 1) on problematic platform implement hs_ctz*/hs_clz* functions in pure C without usage of GNU C builtin functions. or 2) enforce linking of shared libgcc with produced application binary. Such linking needs to be enforced with -shared-libgcc parameter passed to the GNU C in linking step and also by usage of either builtins in the application C code (not library code). My experimental code below shows that this is possible (tested on Solaris/SPARC). Please note that by default on static platform, the static version of libgcc is used and this does not help here. Also please note that usage of builtin in let say RTS library does not help either. I've tested RtsMain.c. The reason is the same like why it's not working in ghc-prim. We can't link *.o or *.a against shared libgcc. {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c86667c..7c615d1 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1651,6 +1651,7 @@ mkExtraObjToLinkIntoBinary dflags = do | gopt Opt_NoHsMain dflags = Outputable.empty | otherwise = vcat [ text "#include \"Rts.h\"", + text "#include <stdio.h>", text "extern StgClosure ZCMain_main_closure;", text "int main(int argc, char *argv[])", char '{', @@ -1662,6 +1663,10 @@ mkExtraObjToLinkIntoBinary dflags = do Just opts -> ptext (sLit " __conf.rts_opts= ") <> text (show opts) <> semi, text " __conf.rts_hs_main = rtsTrue;", + text " printf(\"ctz(argc): %d\\n\", __builtin_ctz(argc));", text " return hs_main(argc,argv,&ZCMain_main_closure,__conf);", char '}', char '\n' -- final newline, to keep gcc happy }}} of course this is just a proof of concept. For real code we would need some place to save the result of the called builtin to prevent GCC from removing the call as an unused value. I guess one added value in {{{__conf}}} just for this case should do the job here. I'm free to implement either of those two solutions or even completely different one, I just need to know your preference in this case. BTW: I'm ccing people from #9340 which looks really related to this issue. If you are not interested in this issue discussion, please un-cc yourself. Thanks! Karel PS: as this is IMHO general issue, I'm not setting SPARC/Solaris as Architecture/OS here... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode
by GHC 19 Dec '15

19 Dec '15

#10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Keywords: cross- | Operating System: Unknown/Multiple compiling | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attempting to cross-compile from linux to windows (after an in-progress fix to #10070) and ran into: {{{ libraries/haskeline/System/Console/Haskeline/Backend/Win32.hsc:170 directive let cannot be handled in cross-compilation mode }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9394: Show data/type family instances with ghci's :info command
by GHC 18 Dec '15

18 Dec '15

#9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance: {{{#!hs *Application> :info Route App class Eq (Route a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where data family Route a1 ... -- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class' instance Eq (Route App) -- Defined at Foundation.hs:48:1 instance Read (Route App) -- Defined at Foundation.hs:48:1 ................. }}} It just shows info about `Route`, then info about `App` separately. When I try this: {{{#!hs *Application> :info (Route App) <interactive>:1:2: parse error on input `Route' }}} I am getting parse error. I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9