November 2014 - ghc-tickets

[GHC] #9737: List ANN in pragmas chapter of user manual
by GHC 01 Apr '15

01 Apr '15

#9737: List ANN in pragmas chapter of user manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- That chapter seems to be a comprehensive listing of pragmas. It should fulfill that promise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception
by GHC 27 Mar '15

27 Mar '15

#8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /System-IO-Error.html The description for IOError refers to module Control.Exception.Exception: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /Control-Exception-Exception.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans
by GHC 27 Mar '15

27 Mar '15

#9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | 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: Compile- Blocked By: | time performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there is a comment on `dep_orphs` claiming this: {{{ , dep_orphs :: [Module] -- ^ Orphan modules (whether home or external pkg), -- *not* including family instance orphans as they -- are anyway included in 'dep_finsts' }}} However, it is not difficult to discover that this is not true: {{{ [ezyang@hs01 ghc-quick]$ cat A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a :: * [ezyang@hs01 ghc-quick]$ cat B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Int = Bool [ezyang@hs01 ghc-quick]$ cat C.hs module C where import B [ezyang@hs01 ghc-quick]$ inplace/bin/ghc-stage2 --show-iface C.hi | grep orphans orphans: GHC.Base GHC.Float B }}} I'm not sure if the comment or the implementation is wrong. Certainly `TcRnDriver` would not work if we removed type family orphans from the list, because we only currently load `imp_orphans` and not `imp_finsts`. This change occured in this commit: {{{ commit 8f212ab5307434edf92c7d10fe0df88ccb5cd6ca Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu May 26 14:30:15 2011 +0100 Rejig the way in which generic default method signatures are checked - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer! diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs index 2542ad3..5aa6959 100644 --- a/compiler/typecheck/TcRnDriver.lhs +++ b/compiler/typecheck/TcRnDriver.lhs @@ -245,7 +245,6 @@ tcRnImports hsc_env this_mod import_decls -- interfaces, so that their rules and instance decls will be -- found. ; loadOrphanModules (imp_orphs imports) False - ; loadOrphanModules (imp_finsts imports) True -- Check type-familily consistency ; traceRn (text "rn1: checking family instance consistency") }}} When did we start adding type family orphans to the list? This commit is to blame (it states that modules with type family orphans are orphans, which means that it will get added to orphan module list in `RnNames` when we import the interface: {{{ commit 98a642cf29781ebd33994a4ecbea6ef07f89bbed Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 3 10:35:08 2012 +0000 Major refactoring of CoAxioms @@ -619,7 +620,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls mi_exp_hash = export_hash, mi_orphan_hash = orphan_hash, mi_flag_hash = flag_hash, - mi_orphan = not (null orph_rules && null orph_insts + mi_orphan = not ( null orph_rules + && null orph_insts + && null orph_fis && null (ifaceVectInfoVar (mi_vect_info iface0))), mi_finsts = not . null $ mi_fam_insts iface0, mi_decls = sorted_decls, @@ -631,12 +634,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls this_mod = mi_module iface0 dflags = hsc_dflags hsc_env this_pkg = thisPackage dflags - (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) - (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) - -- See Note [Orphans] in IfaceSyn - -- ToDo: shouldn't we be splitting fam_insts into orphans and - -- non-orphans? - fam_insts = mi_fam_insts iface0 + (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) + (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) + (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0) fix_fn = mi_fix_fn iface0 }}} I think this is probably a legitimate optimization (keeps interface file smaller), and we try to put it back into effect. The only downside is we'll try to load in the entire `mi_fam_insts` list (mostly harmless sense redundant requests on that front will hit the cache); also, it's more elegant if mi_orph describes orphanness over all orphans. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8877: "if this code is reached, the program will abort" in sparc
by GHC 24 Mar '15

24 Mar '15

#8877: "if this code is reached, the program will abort" in sparc ----------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8857 | ----------------------------+------------------------------------- Hi, sparc, when built with dynamic libraries, fails with a segmentation fault: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140… Possible cause indicated by {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o /tmp/ghc14927_0/ghc14927_2.hc: In function 'stg_PAP_entry': /tmp/ghc14927_0/ghc14927_2.hc:101:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc14927_0/ghc14927_2.hc:101:30: note: if this code is reached, the program will abort }}} It works without shared libraries (see #8857) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8872: hsc cast size warnings on 32-bit Linux
by GHC 24 Mar '15

24 Mar '15

#8872: hsc cast size warnings on 32-bit Linux ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When compiling the gtk package with GHC 7.9.20140308 I get a bunch of warnings as outlined below. I'm on 32-bit system. Apparently this is something that should be reported. {{{ In file included from dist/dist-sandbox- c4fc5f8b/build/Graphics/UI/Gtk/General/Structs_hsc_make.c:1:0: Structs.hsc: In function ‘main’: /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1020:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1020:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1025:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1025:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1029:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1029:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1033:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1033:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1037:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1037:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1042:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1042:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1046:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); ^ Structs.hsc:1046:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:36:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%lld", (long long)(x)); \ ^ Structs.hsc:1051:5: note: in expansion of macro ‘hsc_const’ /home/shana/ghc-20140308/lib/ghc-7.9.20140308/template-hsc.h:38:29: warning: cast from pointer to integer of different size [-Wpointer-to-int- cast] hsc_printf ("%llu", (unsigned long long)(x)); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0
by GHC 24 Mar '15

24 Mar '15

#8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+---------------------------------------- ghc-7.8.1 fails to build on Fedora ARM. This appears to be a regression compared to 7.8.1 RC2. {{{ : chmod +x inplace/bin/runghc inplace/bin/dll-split compiler/stage2/build/.depend-v-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.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted }}} This is the bug report! This happens on both Fedora 20 (current latest stable release) and 21 (in development). The build is against ghc-7.6.3 and llvm 3.3 and 3.4 respectively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8550: GHC builds recursive coerctions when using recursive type families
by GHC 23 Mar '15

23 Mar '15

#8550: GHC builds recursive coerctions when using recursive type families -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} type family F a type instance F () = F () data A where A :: F () ~ () => A x :: A x = A }}} On GHC 7.6.3 it yields a context reduction stack overflow (despite F () ~ () being put into the “solved funeqs” list). In HEAD, a recursive dictionary is built, but then detected: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-unknown-linux): Cycle in coercion bindings [[cobox_ayX{v} [lid] = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} [lid]]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Either this panic needs to be turned into an error, or we need to prevent recursive dictionaries for when solving funeqs (similar to how we do it for `Coercible`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8556: Invalid constructor names are accepted in data declarations
by GHC 23 Mar '15

23 Mar '15

#8556: Invalid constructor names are accepted in data declarations ------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Earlier today, someone was asking on #haskell why the constructor name {{{(^)}}} wouldn't work in GADT definitions. My response was that {{{(^)}}} isn't a constructor name, but much to my surprise, GHC accepts such names in a regular data declaration: {{{ data Foo = F | (^^^^) Int Int }}} This creates a {{{Foo}}} type and value constructor {{{F}}}, but no value constructor {{{(^^^^)}}}. However, in 7.6.3, if DataKinds are enabled, both constructors appear at the type level. In HEAD, the same definition is accepted, with only {{{F}}} existing at the value level, as before. But at the type level, both {{{F}}} and {{{(^^^^)}}} just generate errors that {{{Foo}}} is not a promotable type. At that point, I think there's no question that the declaration should just be ruled out. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9194: Remove magic parsing of (~)
by GHC 23 Mar '15

23 Mar '15

#9194: Remove magic parsing of (~) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It seems that `(~)` has magical parsing: {{{ Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint Prelude> :i (+) -- for comparison class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + }}} Now that type operators do not need to start with a colon, this magic seems unnecessary. The `(~)` syntax does not need to be wired-in, unless I'm missing something. (The ''definition'' of `(~)` needs to be wired in -- it's just the syntax that doesn't need to be.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box
by GHC 23 Mar '15

23 Mar '15

#8727: HLearn test on ubuntu Precise x64 within vagrant Box ----------------------------------+-------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): loadArchive "/home/vagrant/.cabal/lib/x86_64-linux- ghc-7.6.3/HLearn-2.0.0.0/libHSHLearn-2.0.0.0.a": failed {{{ import HLearn.Algebra import Control.DeepSeq import HLearn.Models.Distributions import Statistics.Distribution.Normal dataset = [1,2,3,4,5,6] --dist = train dataset :: Normal Double data Marble = Red | Green | Blue | White deriving (Read,Show,Eq,Ord) simonBag :: [Marble] simonBag = [Red, Red, Red, Green, Blue, Green, Red, Blue, Green, Green, Red, Red, Blue, Red, Red, Red, White] simonDist = train simonBag :: Categorical Double Marble }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18