- ghc-tickets - Haskell.org

[GHC] #14314: Consider changing CC detection strategy
by GHC 04 Oct '17

04 Oct '17

#14314: Consider changing CC detection strategy -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently we grep through the `$CC --version` output to identify the C compiler (see `FP_GCC_VERSION` in `aclocal.m4`). This is error prone (see Phab:D4069). Phyx suggests that we instead just rely on CPP macros. There is a handy list of these [[https://sourceforge.net/p/predef/wiki/Compilers/|here]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better
by GHC 04 Oct '17

04 Oct '17

#12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | 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: -------------------------------------+------------------------------------- INLINE vs NOINLE vs <nothing> for this function https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client… produces distinct figures in all three cases. See https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that <nothing> should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be <nothing>, and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14305: Missing COMPLETE pragmas in release notes for version 8.2.1
by GHC 03 Oct '17

03 Oct '17

#14305: Missing COMPLETE pragmas in release notes for version 8.2.1 -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.2.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: -------------------------------------+------------------------------------- From comment ticket:8779#comment:57 it seems `COMPLETE` pragmas were added in 8.2.1 but I couldn't find them in its [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/8.2.1-notes.… release notes]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13561: Remove unsafe Chan combinators
by GHC 03 Oct '17

03 Oct '17

#13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 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: #4154 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Namely `isEmptyChan` and `unGetChan`. See #4154. Let's delete them for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14304: Instantiated libraries (Backpack) don't get linked with enough deps
by GHC 03 Oct '17

03 Oct '17

#14304: Instantiated libraries (Backpack) don't get linked with enough deps -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Linking) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One downstream instance of this reported at https://github.com/haskell/cabal/issues/4755 Basically, if you instantiate a library q with library p, you need to make sure libHSp.so shows up in its linker dependencies. This is not the case right now. Patch coming (I filed this to get a bug number :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13848: Unexpected order of variable quantification with GADT constructor
by GHC 03 Oct '17

03 Oct '17

#13848: Unexpected order of variable quantification with GADT constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} module Foo where data N = Z | S N data Vec (n :: N) a where VNil :: forall a. Vec Z a VCons :: forall n a. a -> Vec n a -> Vec (S n) a }}} I want to use `TypeApplications` on `VCons`. I tried doing so in GHCi: {{{ GHCi, version 8.2.0.20170523: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. λ> :set -XTypeApplications -XDataKinds λ> :t VCons @Z @Int 1 VNil <interactive>:1:8: error: • Expected a type, but ‘'Z’ has kind ‘N’ • In the type ‘Z’ In the expression: VCons @Z @Int 1 VNil <interactive>:1:11: error: • Expected kind ‘N’, but ‘Int’ has kind ‘*’ • In the type ‘Int’ In the expression: VCons @Z @Int 1 VNil <interactive>:1:17: error: • Couldn't match type ‘'Z’ with ‘Int’ Expected type: Vec Int 'Z Actual type: Vec 'Z 'Z • In the fourth argument of ‘VCons’, namely ‘VNil’ In the expression: VCons @Z @Int 1 VNil }}} Huh? That's strange, I would have expected the first type application to be of kind `N`, and the second to be of kind `*`. But GHC disagrees! {{{ λ> :set -fprint-explicit-foralls λ> :type +v VCons VCons :: forall a (n :: N). a -> Vec n a -> Vec ('S n) a }}} That's downright unintuitive to me, since I explicitly specified the order in which the quantified variables should appear in the type signature for `VCons`. Similarly, if you leave out the `forall`s: {{{#!hs data Vec (n :: N) a where VNil :: Vec Z a VCons :: a -> Vec n a -> Vec (S n) a }}} Then `:type +v` will also report the same quantified variable order for `VCons`. This is perhaps less surprising, since the `n` and `a` in `data Vec (n :: N) a` don't scope over the constructors, so GHC must infer the topological order in which the variables appear in each constructor. But I would certainly not expect GHC to do this if I manually specify the order with `forall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9725: Constraint deduction failure
by GHC 03 Oct '17

03 Oct '17

#9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | 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: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I get a strange error message like this {{{ [1 of 1] Compiling Main ( 08-10.hs, interpreted ) 08-10.hs:254:33: Could not deduce (KnownLoc (ent par1 a)) arising from a use of ‘Hidden'’ from the context (List ConfFamily ts) bound by the type signature for locAware :: List ConfFamily ts => (forall (i :: k). KnownLoc (ent par i) => ConfFamily (Facility (ent par i)) ts) -> Con ConfFamily (On ent par) at 08-10.hs:251:13-160 or from (ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp)) bound by a pattern with constructor MonitorF :: forall (par :: Entity) (mp :: MonitorPoint). KnownLoc ('Monitor par mp) => String -> String -> Observer -> Bool -> Facility ('Monitor par mp), in an equation for ‘h’ at 08-10.hs:254:19-28 In the expression: Hidden' (d f) In an equation for ‘h’: h (Hide f@(MonitorF {})) = Hidden' (d f) In an equation for ‘locAware’: locAware descr = Abstr h where h :: (ent `On` par) -> ConfFamily (ent `On` par) ts h (Hide f@(MonitorF {})) = Hidden' (d f) d :: KnownLoc (ent par i) => Facility (ent par i) -> ConfFamily (Facility (ent par i)) ts d _ = descr Failed, modules loaded: none. }}} I have many language extensions active, such as, `DataKinds`, `ScopedTypeVariables`, etc. If somebody says this indeed looks like a bug, then I'll try to post a minimal reproduction case. ** My reasoning goes like this ** Here are the relevant facts that GHC figured out from a GADT pattern match: `(ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp))` From this I discover these equalities: {{{ ent === 'Monitor (*) par === par1 (**) a === mp (***) }}} Substituring `(*)`^-1^ and `(***)`^-1^ into the given `KnownLoc ('Monitor par1 mp)` results in the desired `KnownLoc (ent par1 a)` Looks like a bug, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13819: GHC Panics
by GHC 03 Oct '17

03 Oct '17

#13819: GHC Panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveFunctor, TypeApplications #-} -- {-# Language ViewPatterns #-} -- {-# Language InstanceSigs, ViewPatterns, TupleSections, GeneralizedNewtypeDeriving, TemplateHaskell, LambdaCase #-} module D where import Data.Coerce import Control.Applicative newtype A a = A (IO a) deriving Functor instance Applicative A where pure = pure @(_ -> WrappedMonad A _) @(_ -> A _) pure instance Monad A where }}} causes a panic {{{ $ ghci -ignore-dot-ghci /tmp/a.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling D ( /tmp/a.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTys w0_a1xc[tau:4] WrappedMonad A w0_a1xe[tau:4] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:809:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14308: GHC panic with invalid expression
by GHC 03 Oct '17

03 Oct '17

#14308: GHC panic with invalid expression ----------------------------------------+--------------------------------- Reporter: d6e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, I recently discovered this expression causes GHC to panic. Shouldn't it handle this more gracefully? Perhaps saying something like "That expression is not valid. <Further Explanation>" Invalid expression: {{{#!hs g :: (a->b) a }}} {{{ Prelude> g :: (a->b) a ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys a_a1Lz[sk:1] b_a1LA[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14110: GHC Panic on over-saturated associated type family
by GHC 03 Oct '17

03 Oct '17

#14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If we over-saturate a type family {{{#!hs {-# Language TypeFamilies, ScopedTypeVariables, PolyKinds, DataKinds #-} import Data.Kind class R (c :: k -> Constraint) where type R_ (c :: k -> Constraint) :: k -> Type instance R Eq where type R_ Eq a = a -> a -> Bool }}} we get {{{ $ ghci -ignore-dot-ghci test.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTys a_a2qu[sk:1] a_a2qu[sk:1] -> Bool [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:809:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5