October 2016 - ghc-tickets

[GHC] #12785: GHC panic, TypeFamily in equality constraint
by GHC 22 Jan '17

22 Jan '17

#12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached module I get {{{ $ ghc --interactive Tree.hs GHCi, version 8.1.20161030: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( Tree.hs, interpreted ) Tree.hs:28:63: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161030 for x86_64-apple-darwin): tcTyVarDetails cobox0_a1eK :: (m_a1ej[sk:2] :: Peano) ~# ('S n_a1eJ[ssk:3] :: Peano) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:457:22 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When switching the call to `SBranchX` in line 29 to a call to `SBranch` the program compiles. So I suspect that the problem is rooted in the extra constraint attached to constructor `SBranchX`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9223: Type equality makes type variable untouchable
by GHC 21 Jan '17

21 Jan '17

#9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ‘a’ with actual type ‘()’ ‘a’ is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ‘a’ is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ‘return’, namely ‘()’ In the first argument of ‘run2’, namely ‘(return ())’ -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12750: hGetContents leads to late/silent failures
by GHC 21 Jan '17

21 Jan '17

#12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: | Owner: massimo.zaniboni | Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error| Blocking: | Related Tickets: #9236 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the same problem described in the closed ticket #9236 This is a test-case https://github.com/massimo- zaniboni/ghc_lazy_file_content_error I tried with ghc 7.10.3 and 8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’
by GHC 20 Jan '17

20 Jan '17

#10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Has anyone seen something like this? {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150519 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy
by GHC 20 Jan '17

20 Jan '17

#12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Oddly this only happens on our build server, not on my local machine. On compilation, I get: {{{ [187 of 273] Compiling Query.Order ( Query/Order.hs, dist/build/Query/Order.o ) Query/Order.hs:340:1: warning: [-Wredundant-constraints] • Redundant constraint: MonadBaseControl IO m • In the type signature for: updateOrdersSuccess :: (MonadBaseControl IO m, MonadTransaction m) => m () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): piResultTy Maybe Int64 a1_a4WiL Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The configuration parameters are: {{{ configureFlags: --verbose --prefix=/nix/store /qxfjd5jxr593dn43i3659s86d0rdllyv-circuithub-api-0.0.4 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-circuithub-api-0.0.4.drv-0/package.conf.d --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --disable-shared --enable-library-vanilla --disable- executable-dynamic --disable-tests }}} I've attached Query/Order.hs, but you won't be able to compile it stand- alone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12162: Concatenation of type level symbols missing
by GHC 20 Jan '17

20 Jan '17

#12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type level string literals (of kind Symbol), should have a concatenation operation. It's very useful, e.g., in the library for strongly typed relations that we have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11736: Allow unsaturated uses of unlifted types in Core
by GHC 19 Jan '17

19 Jan '17

#11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently Core Lint checks for unsaturated uses of unlifted types in . These are easily produced in the new type-indexed `Typeable` scheme. For instance, consider solving for `Typeable # (Array# Int)`: * We decompose the application into wanteds `Typeable (* -> #) Array#` and `Typeable * Int` * We construct dictionaries for both, giving us a term `typeRepArray# :: TypeRep (* -> #) Array#` While nothing seems to blow up with this patch, {{{#!patch diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 99625c9..2c401de 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -1040,7 +1040,7 @@ lintType ty@(TyConApp tc tys) = lintType ty' -- Expand type synonyms, so that we do not bogusly complain -- about un-saturated type synonyms - | isUnliftedTyCon tc || isTypeSynonymTyCon tc || isTypeFamilyTyCon tc + | isTypeSynonymTyCon tc || isTypeFamilyTyCon tc -- Also type synonyms and type families , length tys < tyConArity tc = failWithL (hang (text "Un-saturated type application") 2 (ppr ty)) }}} I otherwise have no reason to believe that this is safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11789: Flag suggestion does not always work
by GHC 18 Jan '17

18 Jan '17

#11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Driver | Version: 8.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Usually, GHC is very helpfully telling me about misspelled flags, but sometimes it fails. Did not yet look deeper, but when I wrote `-fppr- cols=1000` it did not suggest `-dppr-cols=1000`. I am not sure if this is due to the `=` or whether it branches on `-f` vs. `-d` earlier. This surely can be improved! Likely newcomer-friendly.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9137: A way to match RULES only for literals
by GHC 16 Jan '17

16 Jan '17

#9137: A way to match RULES only for literals ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In `GHC/Enum` we have {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} -- This rule ensures that in the common case (delta = 1), we do not do the check here, -- and also that we have the chance to inline up_fb, which would allow the constructor to be -- inlined and good things to happen. -- We do not do it for Int this way because hand-tuned code already exists, and -- the special case varies more from the general case, due to the issue of overflows. }}} This rule would be useful for all literals, not just for `1`. I remember a discussion that such a rule would be more useful if we had a way to specify that, for example (random syntax). {-# RULES "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => enumDeltaToIntegerFB c n x d = up_fb c n x d #-} I’m reporting this now to be able to link to it from #9136, where this feature might also help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs
by GHC 16 Jan '17

16 Jan '17

#11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of now, GHC has no option to dump the parse tree of a given Haskell source file. `-ddump-parsed` only displays the pretty-printed AST structure, and cannot be used to inspect parse trees. An existing implementation of such a feature is present in apply- refact(https://github.com/mpickering/apply-refact) by invoking the tool as `refactor --debug`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10