October 2018 - ghc-tickets

[GHC] #15799: GHC panic (and warnings)
by GHC 07 Mar '19

07 Mar '19

#15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- On the [https://phabricator.haskell.org/D5229 visible kind application] differential, {{{#!hs {-# Language CPP #-} {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language PatternSynonyms #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} {-# Language TypeApplications #-} {-# Language FlexibleContexts #-} {-# Language FlexibleInstances #-} {-# Language InstanceSigs #-} import qualified GHC.TypeLits as TypeLits import GHC.TypeLits (Nat, KnownNat) import Data.Kind data Op obj = Op obj type family UnOp (op_a :: Op obj) :: obj where UnOp ('Op obj) = obj class Ríki (obj :: Type) where type (-->) :: Op obj -> obj -> Type type (<--) :: obj -> Op obj -> Type unop :: forall (a :: obj) (b :: obj). (a <-- 'Op b) -> ('Op b --> a) data (<=) :: Op Nat -> Nat -> Type where LessThan :: (KnownNat (UnOp op_a), KnownNat b, UnOp op_a TypeLits.<= b) => (op_a <= b) newtype (>=) :: Nat -> Op Nat -> Type where Y :: (a <= b) -> (b >= a) instance Ríki Nat where type (-->) = (<=) type (<--) = (>=) unop :: (a >= b) -> (b <= a) unop GreaterThan = LessThan pattern GreaterThan :: () => (KnownNat (UnOp b), KnownNat a, UnOp b <= a) => a >= b pattern GreaterThan = Y LessThan }}} {{{ $ ghci -ignore-dot-ghci 573_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 573_bug.hs, interpreted ) WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {b_a1Em a_a1En} tenv [a1Em :-> b_a1Em[sk:0], a1En :-> a_a1En[sk:0]] cenv [] tys [KnownNat (UnOp b_a1Em[sk:1]), KnownNat a_a1En[sk:1], (UnOp b_a1Em[sk:1] |> {co_a1HN}) <= a_a1En[sk:1]] cos [] needInScope [a1HN :-> co_a1HN] WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {b_a1Jo a_a1Jp} tenv [a1Em :-> b_a1Jo[tau:3], a1En :-> a_a1Jp[tau:3]] cenv [] tys [KnownNat (UnOp b_a1Em), KnownNat a_a1En, (UnOp b_a1Em |> {co_a1HN}) <= a_a1En] cos [] needInScope [a1HN :-> co_a1HN] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): tcEvVarPred irred_a1Js (UnOp b_a1Jo[tau:3] |> {co_a1HN}) <= a_a1Jp[tau:3] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1998:20 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12509: ghci -XSafe fails in an inscrutable way
by GHC 06 Mar '19

06 Mar '19

#12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | 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: -------------------------------------+------------------------------------- Trying to run `ghci -XSafe` produces the following output: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help <interactive>:1:6: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:30: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:46: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:70: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:94: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:111: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:135: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:159: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:176: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} I'm not sure whether this should work, but in any case the error message is horrible. I tried adding `-trust base` to no avail. For comparison, ghc-7.10.3 starts with no trouble: {{{ > ghci -XSafe GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> }}} (Motivation: I'm using ghci in Safe mode to track down import problems with SafeHaskell. As a workaround, I can use `:set -XSafe` after ghci's startup is done.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15837: Hadrian should build dynamically linked ghc binary
by GHC 06 Mar '19

06 Mar '19

#15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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: -------------------------------------+------------------------------------- The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this: 1. Add new .cabal file field extra-dynamic-library-flavours (see [https://github.com/haskell/cabal/pull/5606 this PR]). 2. Use .cabal extra-dynamic-library-flavours for the RTS (see [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this comment], depends on 1.) 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd71… #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). 5. Use the correct relative path to the dynamically linked libraries (see [https://phabricator.haskell.org/D5281 this change], depends on 3. and 4.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?)
by GHC 06 Mar '19

06 Mar '19

#12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.0.20160511. Example from the user guide: [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts… #constraints-in-kinds Constraints in kinds] {{{#!hs type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" }}} Deriving a standalone `Show` instance *without* the constraint works fine {{{#!hs deriving instance Show (T a) }}} but I couldn't define a `Show` instance given the constraints: {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit a0’ -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘Show’, namely ‘T a’ -- In the stand-alone deriving instance for ‘Show (T a)’ deriving instance Show (T a) }}} let's add constraints {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit lit’ -- • In the first argument of ‘Show’, namely ‘T (a :: lit)’ -- In the instance declaration for ‘Show (T (a :: lit))’ instance IsTypeLit lit ~ 'True => Show (T (a :: lit)) where }}} let's derive for a single literal {{{#!hs -- • Illegal type synonym family application in instance: -- T Nat -- ('Data.Type.Equality.C:~ -- Bool -- (IsTypeLit Nat) -- 'True -- ('GHC.Types.Eq# Bool Bool (IsTypeLit Nat) 'True <>)) -- 42 -- • In the stand-alone deriving instance for ‘Show (T (42 :: Nat))’ deriving instance Show (T (42 :: Nat)) }}} same happens with {{{#!hs instance Show (T 42) where }}} ---- The documentation > Note that explicitly quantifying with `forall a` is not necessary here. seems to be wrong since removing it results in {{{ tVDv.hs:10:17-18: error: … • Expected kind ‘a’, but ‘42’ has kind ‘Nat’ • In the first argument of ‘T’, namely ‘42’ In the type ‘T 42’ In the definition of data constructor ‘MkNat’ Compilation failed. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13208: Do two-phase inlining in simpleOptPgm
by GHC 06 Mar '19

06 Mar '19

#13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | 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: -------------------------------------+------------------------------------- As of #12988, having `simpleOptPgm` leave β-redexes lying around is painful because it requires a special loophole in Core Lint to allow a jump inside a β-redex. We'd rather use a two-phase approach, mirroring the simplifier's `preInlineUnconditionally` and `postInlineUnconditionally`, so we can aggressively eliminate β-redexes without fear of exponential blowup. Consider: {{{ joinrec j1 x = e1 in join j2 x y = jump j1 e2 in jump j2 e3 e4 }}} Since `j2` is only used once, it gets inlined. But `simpleOptPgm` only performs inlining //after// a binding is simplified, so we end up here: {{{ joinrec j1 x = e1' in (\x y -> jump j1 e2') e3' e4' }}} Since `e2'` was already simplified, performing the β-reduction here risks exponential blowup for the same reason it can happen in the simplifier (see the Secrets paper; `perf/compiler/T783` is a live example, increasing in allocs by over 80% if we re-simplify here). We //could// just `let`-bind `e3'` and `e4'` (carefully avoiding capturing free occurrences of `x` in `e4'`), but not if one them is actually a type argument. Well, okay, we //could// introduce a type `let`, but doing that here means the desugarer can now return a type `let` and we're not prepared for that. (Specifically, under certain circumstances, the simplifier never runs in between the desugarer and Float Out, and the latter breaks in the presence of type `let`.) So for the moment, we leave the β-redex there, but this needs a special rule just for β-redexes because normally you can't have a jump under a lambda (or an application, for that matter). In the long term, we'd prefer to take the simplifier's approach instead: If we want to inline something because it only occurs once (even though it may be big), we add it to the substitution //before// simplifying it so that we only simplify it once. This means the substitution has to carry lexical closures around, though, just like the simplifier does (see `SimplSR`'s `ContEx` disjunct), so it's not trivial. The `simpleOptPgm` β-redexes are the only reason for the special rule in Core Lint (see Note [Beta redexes] in `CoreLint.hs`), so once this is done we can be rid of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal
by GHC 05 Mar '19

05 Mar '19

#14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Template | Version: 8.3 Haskell | 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: -------------------------------------+------------------------------------- Back in September 2015, I [https://mail.haskell.org/pipermail/libraries/2015-September/026117.html proposed] using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12596: can't find interface-file declaration
by GHC 05 Mar '19

05 Mar '19

#12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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: -------------------------------------+------------------------------------- full repro at https://github.com/mwotton/liftwoes/issues/1 ``` /home/mark/projects/liftwoes/src/Lib.hs:14:11: error: • Can't find interface-file declaration for variable Data.Text.Internal.pack Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the first argument of ‘(:)’, namely ‘Data.Text.Internal.pack ((:) 'A' [])’ In the first argument of ‘HS.fromList’, namely ``` {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Data import qualified Data.Set as HS import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Time -- import Instances.TH.Lift import Instances import Language.Haskell.TH.Syntax table = $(do r <- runIO (HS.fromList . T.lines <$> T.readFile "/usr/share/dict/words") [|r|] ) someFunc = do print $ HS.member "foo" table }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10892: ApplicativeDo should use *> and <*
by GHC 05 Mar '19

05 Mar '19

#10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #13633: testwsdeque failure on POWER8
by GHC 04 Mar '19

04 Mar '19

#13633: testwsdeque failure on POWER8 ---------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: SMP | Operating System: Linux Architecture: powerpc64 | Type of failure: Runtime crash Test Case: rts/testwsdeque | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- On a POWER8 `testwsdeque` fails occasionally under load: {{{ Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 ) Stderr ( testwsdeque ): internal error: FAIL: 277808608 3 13 (GHC version 8.3.20170430 for powerpc64le_unknown_linux) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15658: strange inferred kind with TypeInType
by GHC 04 Mar '19

04 Mar '19

#15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- This type family has a strange kind to begin with: {{{ {-# Language TypeFamilies , TypeInType #-} type family F f a :: a }}} But it gets even stranger when you ask ghci what it thinks about F: {{{ > :k F F :: * -> forall a -> a }}} There is a forall which doesn't seem to bind any variables and hasn't got the customary delimiting dot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9