January 2018 - ghc-tickets

[GHC] #14742: Unboxed sums can treat Int#s as Word#s
by GHC 16 Nov '18

16 Nov '18

#14742: Unboxed sums can treat Int#s as Word#s -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following module: {{{ {-# language MagicHash, UnboxedSums #-} {-# options_ghc -ddump-stg -dppr-debug -fprint-explicit-kinds -ddump-to- file #-} module Bug where import GHC.Prim import GHC.Types mkUnboxedSum :: () -> (# Float# | Int# #) mkUnboxedSum _ = (# | 9# #) {-# noinline mkUnboxedSum #-} foo :: Int foo = case mkUnboxedSum () of (# | i# #) -> I# i# (# f# | #) -> 8 }}} The full .dump-stg is attached. An abbreviation of the case statement in foo is: {{{ case (...) of (...) { ghc-prim:GHC.Prim.(#,,#){(w) d 89} ((us_g1h9{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) ((us_g1ha{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) ((us_g1hb{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.FloatRep{(w) d 63V})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.FloatRep{(w) d 63V})) -> case (us_g1h9{v} [lid] :: ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc-prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) :: Prim IntRep of ((tag_g1hc{v} [lid] :: ghc-prim:GHC.Prim.Int#{(w) tc 3s}) :: ghc-prim:GHC.Prim.Int#{(w) tc 3s}) { __DEFAULT -> ghc-prim:GHC.Types.I#{(w) d 6i} [8#]; 2# -> ghc-prim:GHC.Types.I#{(w) d 6i} [(us_g1ha{v} [lid] :: ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc-prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J}))]; }; }}} Note that: * `us_g1h9 :: Any (TYPE WordRep)`; * `us_g1ha :: Any (Type WordRep)`; * `tag_g1hc :: Int#`; * The `2#` alternative passes `us_g1ha` to an `I#` constructor. This seems wrong to me. It comes about because `slotPrimRep . primRepSlot` (in RepType) is not the identity. StgLint found this while I was working on ticket:14541 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14343: bad pretty-printing of types with promoted data types
by GHC 15 Nov '18

15 Nov '18

#14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | 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: -------------------------------------+------------------------------------- {{{ > :set -XDataKinds > :set -XPolyKinds > data Proxy k = Proxy > _ :: Proxy '[ 'True ] error: Found hole: _ :: Proxy '['True] > _ :: Proxy '['True] error: Invalid type signature: _ :: ... Should be of form <variable> :: <type> }}} Alternatively, this could be attributed to the parser/lexer doing an insufficient job there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr`
by GHC 15 Nov '18

15 Nov '18

#10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | 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 Revisions: | -------------------------------------+------------------------------------- An `HsExpr` should look exactly as a user wrote some Haskell code. Its pretty printer should therefore be quite dumb. Just print out the code! But a few places in GHC create `HsExpr`s and aren't scrupulous with regard to adding `HsPar` nodes where source syntax would need them. Thus, well- meaning souls have added `pprParendExpr` calls to the `HsExpr` pretty- printer to try to cover these cases. Simon and I [https://phabricator.haskell.org/D1219#34199 think] that we should remove all recursive uses of `pprParendExpr` from the `HsExpr` pretty-printer and instead add the `HsPar`s where necessary. It was recently reported that the following test cases break when simply removing `pprParendExpr`: {{{ Unexpected failures: deriving/should_fail T4846 [stderr mismatch] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) ghci/scripts T10248 [bad stderr] (ghci) indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang10 [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang17 [stderr mismatch] (normal) typecheck/should_fail T8603 [stderr mismatch] (normal) typecheck/should_fail tcfail177 [stderr mismatch] (normal) }}} See also considerable commentary on Phab:D1114. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14293: View patterns with locally defined functions in restructuring don't compile
by GHC 14 Nov '18

14 Nov '18

#14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} foo x = x Just (id -> res) = pure 'a' -- WORKS Just (foo -> res') = pure 'a' -- FAILS bar (foo -> res) = res -- WORKS {- [1 of 1] Compiling Main ( T14293.hs, interpreted ) T14293.hs:6:7-9: error: Variable not in scope: foo :: Char -> t | 6 | Just (foo -> res') = pure 'a' | ^^^ Failed, 0 modules loaded. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13114: UniqSet definition seems shady
by GHC 13 Nov '18

13 Nov '18

#13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Currently, {{{#!hs type UniqSet a = UniqFM a }}} The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is {{{#!hs newtype UniqSet a = US (UniqFM a) }}} Unfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s
by GHC 11 Nov '18

11 Nov '18

#11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Haskell2010 states: > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. Consider the following two modules: {{{#!hs -- module Main (main) where import Main2 (main) }}} {{{#!hs module Main2 (main) where main :: IO () main = return () }}} A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with {{{ $ ghci Main.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 2] Compiling Main2 ( Main2.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’ Failed, modules loaded: Main2. }}} For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9692: Template Haskell reification for Data Families is buggy?
by GHC 08 Nov '18

08 Nov '18

#9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TemplateHaskell | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-instantiated type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituing is non-trivial this way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly
by GHC 08 Nov '18

08 Nov '18

#14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be observed on GHC 8.0.1 or later: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam a data instance Fam Int data instance Fam Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:15: error: Conflicting family instance declarations: Fam Int = -- Defined at Bug.hs:5:15 Fam Int = -- Defined at Bug.hs:6:15 | 5 | data instance Fam Int | ^^^ }}} Notice how GHC attempts to pretty-print the RHS by using a `=` symbol, but there is no RHS! This gets even more confusing with this program, which requires GHC HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam :: k -> * data instance Fam :: * -> * data instance Fam :: * -> * }}} {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170818: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:15: error: Conflicting family instance declarations: Fam = -- Defined at Bug.hs:6:15 Fam = -- Defined at Bug.hs:7:15 | 6 | data instance Fam :: * -> * | ^^^ }}} Not only is there no RHS, but the kind signatures of each instance aren't printed either. This is an issue, since the entire reason why the two instances conflict are because of their kinds! We should rethink how data family instances are pretty printer here to avoid this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b)
by GHC 08 Nov '18

08 Nov '18

#11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13933: Support Typeable instances for types with coercions
by GHC 07 Nov '18

07 Nov '18

#13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE GADTs, TypeApplications, TypeInType #-} module Bug where import Type.Reflection data G a where MkG :: a ~ Bool => G a rep = typeRep @MkG }}} I get {{{ Bug.hs:10:7: error: • No instance for (Typeable <>) arising from a use of ‘typeRep’ • In the expression: typeRep @MkG In an equation for ‘rep’: rep = typeRep @MkG | 10 | rep = typeRep @MkG | }}} First off, the error message is confusing, mentioning the mysterious `<>`. But more importantly, it would be nice if the `Typeable` mechanism supported coercions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2