December 2016 - ghc-tickets

[GHC] #12809: TYPE 'UnboxedTupleRep is still a lie
by GHC 19 Jan '17

19 Jan '17

#12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: -------------------------------------+------------------------------------- The new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good. But there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level. Simon and I have cooked up a new scheme to handle this, summarized in these definitions: {{{#!hs TYPE :: RuntimeRep -> Type -- highly magical, just as before type RuntimeRep = [UnaryRep] -- this bit is the new part data UnaryRep = PtrRepLifted -- like the old RuntimeRep type | PtrRepUnlifted | IntRep | ... type Lifted = '[PtrRepLifted] -- a very common case type Type = TYPE Lifted -- good old Type }}} The `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however. The interpretation of this is that the kinds now include a ''list'' of unary representation forms. A "unary representation" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.) This will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature. Patch will be written this weekend, with any luck. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12987: Core lint error with levity polymorphism
by GHC 19 Jan '17

19 Jan '17

#12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a Prelude GHC.Types> }}} works, but with `-dcore-lint` I get a core lint error {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> :set -dcore-lint Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a *** Core Lint errors : in result of Tidy Core *** <no location info>: warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q’ kind: TYPE rep_a17P <no location info>: warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ kind: TYPE rep_a17P *** Offending Program *** add [InlPrag=INLINE] :: forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType <S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 [Occ=Once] :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] <rep_a17P>_N <a_a17Q>_N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *))}] add = \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] <rep_a17P>_N <a_a17Q>_N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *)) $trModule1_r18t :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule1_r18t = TrNameS "interactive"# $trModule2_r18D :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule2_r18D = TrNameS "Ghci1"# $trModule :: Module [GblId, Caf=NoCafRefs, Str=DmdType] $trModule = Module $trModule1_r18t $trModule2_r18D $tc'C:NUM1_r18E :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM1_r18E = TrNameS "'C:NUM"# $tc'C:NUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM = TyCon 13508714812303496948## 14031386194776682412## $trModule $tc'C:NUM1_r18E $tcNUM1_r18F :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM1_r18F = TrNameS "NUM"# $tcNUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM = TyCon 18330307158587089132## 17437587248867430906## $trModule $tcNUM1_r18F *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #12973: No levity-polymorphic arguments
by GHC 19 Jan '17

19 Jan '17

#12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed in our [http://cs.brynmawr.edu/~rae/papers/2017/levity/levity.pdf draft paper] on levity polymorphism, you cannot have a levity-polymorphic argument. Here is an example: {{{#!hs {-# LANGUAGE RebindableSyntax, TypeInType, ExplicitForAll #-} module Bug where import qualified Prelude as P import GHC.Exts class Num (a :: TYPE r) where (+) :: a -> a -> a fromInteger :: P.Integer -> a foo :: forall (a :: TYPE r). Num a => a foo = 3 + 4 }}} HEAD panics in `kindPrimRep`, but the code should be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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

[GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type
by GHC 15 Jan '17

15 Jan '17

#12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- I've noticed it as a build failure on openbsd-6 but on linux behaviour is strange as well. Build failure: {{{ libraries/base/System/Posix/Types.hs:217:100: error: * No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Fractional CTimer) }}} On openbsd-6.0 timer_t is an int32: {{{ # gcc -E /usr/include/time.h | grep timer_t typedef __int32_t __timer_t; typedef __timer_t timer_t; }}} On amd64-linux-glibc it's void*: {{{ $ gcc -E /usr/include/time.h | grep timer_t typedef void * __timer_t; typedef __timer_t timer_t; }}} But base's configure detects it as Double (by chance) on amd64-linux- glibc. {{{ System.Posix.Types> :t CTimer CTimer :: Double -> CTimer }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12795: Add more types to System.Posix.Types
by GHC 15 Jan '17

15 Jan '17

#12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- A whole lot of types are still missing from `System.Posix.Types` as noted in a TODO comment in the code: {{{ --- ToDo: blksize_t, clockid_t, blkcnt_t, fsblkcnt_t, fsfilcnt_t, id_t, key_t --- suseconds_t, timer_t, useconds_t }}} Specifically the lack of wrappers for blkcnt_t is causing trouble because it's forcing HFuse to re-implement `unix`'s `FileStatus` type to include the missing `st_blocks` field. See [https://hackage.haskell.org/package/HFuse/docs/System- Fuse.html#t:FileStat FileStat docs on Hackage]. I have patches for `base` and `unix` ready to add wrappers for all the types the comment mentions, let's see if I can figure out how to use Phab ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10073: Idris REPL is pretty and we can too
by GHC 14 Jan '17

14 Jan '17

#10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Manual for configuring colors in the Idris REPL: https://github.com/idris- lang/Idris-dev/wiki/Manual#colours Screenshot: http://i.imgur.com/rYHCI4T.png Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5