October 2016 - ghc-tickets

[GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing.
by GHC 21 May '17

21 May '17

#11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8048: Register spilling produces ineffecient/highly contending code
by GHC 21 May '17

21 May '17

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: register | Operating System: Unknown/Multiple allocator spill | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values. Consider the following program: {{{ {-# LANGUAGE BangPatterns #-} module Spill where import GHC.Exts data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int spill :: S -> S -> S -> S spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _) = S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u) }}} Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like: {{{ _cnc: addq $80,%r12 cmpq 144(%r13),%r12 ja _cni movq $Spill.S_con_info,-72(%r12) movq 32(%rbp),%rax movq %rax,-64(%r12) movq 24(%rbp),%rax movq %rax,-56(%r12) movq 16(%rbp),%rax movq %rax,-48(%r12) movq 8(%rbp),%rax movq %rax,-40(%r12) movq 40(%rbp),%rax movq %rax,-32(%r12) movq 48(%rbp),%rax movq %rax,-24(%r12) movq 56(%rbp),%rax movq %rax,-16(%r12) movq 64(%rbp),%rax movq %rax,-8(%r12) movq 7(%rbx),%rax movq %rax,0(%r12) leaq -71(%r12),%rbx addq $72,%rbp jmp *0(%rbp) }}} {{{ _csv: movq 63(%rbx),%rax movq %rax,-56(%rbp) movq 55(%rbx),%rax movq %rax,-48(%rbp) movq 47(%rbx),%rax movq %rax,-40(%rbp) movq 39(%rbx),%rax movq %rax,-32(%rbp) movq 31(%rbx),%rax movq %rax,-24(%rbp) movq 23(%rbx),%rax movq %rax,-16(%rbp) movq 71(%rbx),%rax movq %rax,-8(%rbp) movq 15(%rbx),%rax movq %rax,0(%rbp) }}} And likewise for LLVM: {{{ .LBB10_1: # %coZ movq 7(%rbx), %rcx movq $Spill_S_con_info, 8(%rax) movq 8(%rbp), %rdx movq %rdx, 16(%rax) movq 16(%rbp), %rdx movq %rdx, 24(%rax) movq 24(%rbp), %rdx movq %rdx, 32(%rax) movq 32(%rbp), %rdx movq %rdx, 40(%rax) movq 40(%rbp), %rdx movq %rdx, 48(%rax) movq 48(%rbp), %rdx movq %rdx, 56(%rax) movq 56(%rbp), %rdx movq %rdx, 64(%rax) movq 64(%rbp), %rdx movq %rdx, 72(%rax) movq %rcx, (%r12) movq 72(%rbp), %rax leaq 72(%rbp), %rbp leaq -71(%r12), %rbx jmpq *%rax # TAILCALL }}} Quoting from #ghc "the [register allocator] core algo is '96 vintage". Improvements are needed; * Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention * Sink memory reads in order to reduce register pressure -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12136: SIGABRT on right-shift operation against long negative integer
by GHC 20 May '17

20 May '17

#12136: SIGABRT on right-shift operation against long negative integer --------------------------------------+---------------------------------- Reporter: khibino | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When the code like bellow is executed, the '''shiftR''' call causes SIGABRT. c128.hs {{{#!hs import Data.Bits x:: Integer x = 1 - (1 `shiftL` (128 + 64)) main :: IO () main = print $ x `shiftR` 128 }}} I make this report using examples in GHC 7.10.3, and I found the same problem in GHC 8.0.1 too. backtrace using GDB {{{ % ghc -O0 c128.hs [1 of 1] Compiling Main ( c128.hs, c128.o ) Linking c128 ... % gdb ./c128 GNU gdb (Debian 7.10-1+b1) 7.10 ... Reading symbols from ./c128...(no debugging symbols found)...done. (gdb) run Starting program: /home/hibi/src/haskell/crash/Haskell/c128 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff6ed4478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: そのようなファイルやディレクトリはありません. (gdb) bt #0 0x00007ffff6ed4478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff6ed58fa in __GI_abort () at abort.c:89 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () #3 0x000000000046e004 in salz_info () #4 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () (gdb) disas Dump of assembler code for function integer_gmp_mpn_rshift_2c: 0x0000000000471630 <+0>: push %r13 ... 0x00000000004716d8 <+168>: jne 0x4716c0 <integer_gmp_mpn_rshift_2c+144> 0x00000000004716da <+170>: callq 0x402c80 <abort@plt> => 0x00000000004716df <+175>: nop 0x00000000004716e0 <+176>: lea 0x0(,%rdx,8),%rdx ... End of assembler dump. (gdb) }}} I found '''abort''' call in '''integer_gmp_mpn_rshift_2c'''. ghc-7.10.3/libraries/integer-gmp2/cbits/wrappers.c {{{#!c mp_limb_t integer_gmp_mpn_rshift_2c (mp_limb_t rp[], const mp_limb_t sp[], const mp_size_t sn, const mp_bitcnt_t count) { ... // round if non-zero bits were shifted out if (nz_shift_out) if (mpn_add_1(rp, rp, rn, 1)) abort(); /* should never happen */ return rp[rn-1]; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors
by GHC 19 May '17

19 May '17

#11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: GADTs | Operating System: Linux Architecture: x86 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://www.youtube.com/watch?v=6snteFntvjM A Practical Introduction to Haskell GADTs] from LambdaConf 2015, example from attachment Hole.hs: {{{#!hs {-# LANGUAGE GADTs #-} data STy ty where SInt :: STy Int SBool :: STy Bool SMaybe :: STy a -> STy (Maybe a) zero :: STy ty -> ty zero ty = case ty of SInt -> 5 SBool -> False SMaybe a -> _ }}} When running with "GHCi, version 7.11.20151226": {{{ % ghci -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.11.20151226: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: error: • Found hole: _ :: ty Where: ‘ty’ is a rigid type variable bound by the type signature for: zero :: forall ty. STy ty -> ty at /tmp/Hole.hs:8:9 • In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } • Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) Failed, modules loaded: none. Prelude> }}} when older versions (GHCi version 7.10.2) refine the type of `_` to `Maybe a`: {{{ % ghci-7.10.2 -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: Found hole ‘_’ with type: Maybe a Where: ‘a’ is a rigid type variable bound by a pattern with constructor SMaybe :: forall a. STy a -> STy (Maybe a), in a case alternative at /tmp/Hole.hs:12:3 Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } Failed, modules loaded: none. Prelude> }}} Regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12468: GADTs don't refine hole types
by GHC 19 May '17

19 May '17

#12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apologies if this is a dupe. I did look! {{{ #!haskell {-# LANGUAGE GADTs #-} data T a where I :: T Int f :: T a -> a f I = _ }}} This gives the type error: {{{ • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the type signature for: f :: forall a. T a -> a at test.hs:6:6 • In the expression: _ In an equation for ‘f’: f I = _ • Relevant bindings include f :: T a -> a (bound at test.hs:7:1) }}} It should say something about `a` being `Int` in this branch. I'm using GHC 8.0.1 on OSX El Capitan. I think this may be a regression; I have a vague memory of it working with GHC 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11439: Request for comments: Allow duplicate type signatures
by GHC 17 May '17

17 May '17

#11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Interested in feedback (Code inspired by [http://www.cs.ox.ac.uk/projects/utgp/school/idris-tutorial.pdf Idris tutorial]) {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue x = x sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Allow duplicate type signatures: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum :: SBool True -> Natural -> Natural sum STrue x = x sum :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Where {{{#!hs data SBool b where STrue :: SBool True SFalse :: SBool False type family IsSingleton (b :: Bool) :: Type where IsSingleton True = Natural IsSingleton False = [Natural] }}} ---- == Behaviour == You could do something fancy but I would be happy with a check that any duplicate type signature is a specialization of the ''top'' top-level one, this would allow something like this: {{{#!hs length :: [a] -> Int length :: [()] -> Int length [] = 0 length (_:xs) = 1 + length xs }}} Which isn't very useful, hah what ever. ---- == Benefits == Mainly compiler-checked documentation, for the `sum` function we make it clearer that a `STrue` gives you `Natural -> Natural` while `SFalse` gives you `[Natural] -> Natural`. This is most apparent in the final syntax idea: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural @False :: _ -> [Natural] -> Natural }}} Reader need not look at definition of `IsSingleton`, it is fully described by the duplicate signatures. See ''lens'' where most functions have some kind of type specialisation declared in comments: [https://hackage.haskell.org/package/lens-4.13/docs /Control-Lens-Fold.html#v:-94--63- (^?)] whose type is `(^?) :: s -> Getting (First a) s a -> Maybe a`: {{{#!hs (^?) :: s -> Getter s a -> Maybe a (^?) :: s -> Fold s a -> Maybe a (^?) :: s -> Lens' s a -> Maybe a (^?) :: s -> Iso' s a -> Maybe a (^?) :: s -> Traversal' s a -> Maybe a }}} ---- == Alternative syntax == Throwing it out there, regardless of ambiguity: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural :: SBool True -> Natural -> Natural sum STrue x = x :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... :: SBool True -> Natural -> Natural sum STrue x = x ... :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... @True :: _ -> Natural -> Natural sum STrue x = x ... @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural sum STrue x = x @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12600: Overloaded method causes insufficient specialization
by GHC 13 May '17

13 May '17

#12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | 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: -------------------------------------+------------------------------------- The `foo` function in the following code does not get specialized completely by `ghc -O2`, even though all the overloaded functions in the module are marked `INLINE`. Specifically, it gets compiled into a call to a function with an `Eq Int` dictionary passed at runtime. {{{#!hs module Foo where class Eq1 f where eq1 :: (Eq a) => f a -> f a -> Bool data F a = F !a !a data G f a = G !(f a) !(f a) instance Eq1 F where eq1 = \(F a b) (F c d) -> -- In order to reproduce the problem, the body of this function needs to be -- large enough to prevent GHC from voluntarily inlining it. larger $ larger $ larger $ larger $ larger $ larger $ a == c && b == d {-# INLINE eq1 #-} larger :: a -> a larger = id {-# NOINLINE larger #-} instance (Eq1 f) => Eq1 (G f) where eq1 = \(G a b) (G c d) -> eq1 a c && eq1 b d {-# INLINE eq1 #-} foo :: G F Int -> G F Int -> Bool foo a b = eq1 a b }}} Looking at the dumps, it looks like there may be a problem is the specializer. It creates a specialization of `eq1` with the type `(Eq a) => G F a -> G F a -> Bool` rather than the fully-specialized type: `G F Int -> G F Int -> Bool` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym
by GHC 12 May '17

12 May '17

#11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- For convenience, I'll use GHCi to demonstrate flag behavior. First, we define a file: ``` {-# LANGUAGE TypeInType #-} import Data.Kind type Star = Type newtype T k (t :: k) = T () ``` Next, we load it up in GHCi, WITHOUT `-XTypeInType`. Now we observe strange behavior: ``` ezyang@sabre:~$ ghc-8.0 --interactive C.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( C.hs, interpreted ) Ok, modules loaded: Main. *Main> :k T Type Int T Type Int :: * *Main> :k T Star Int <interactive>:1:3: error: • Data constructor ‘Star’ cannot be used here (Perhaps you intended to use DataKinds) • In the first argument of ‘T’, namely ‘Star’ In the type ‘T Star Int’ ``` Of course, if we pass `-TypeInType` to GHCi that fixes the problem (BTW, `DataKinds` does NOT solve the problem.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5