- ghc-tickets - Haskell.org

[GHC] #15760: Preserve parens in TH
by GHC 03 Dec '18

03 Dec '18

#15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 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: -------------------------------------+------------------------------------- Template Haskell supports parentheses in its AST. So does GHC. Yet GHC casually discards parentheses when desugaring TH quotes. We should preserve them. I was originally thinking that this could get rid of `Note [Adding parens for splices]` in Convert, but that processing would still be necessary if we are converting TH AST that did not come from a quote. Actually, it gets worse with this change, because we don't want to add ''redundant'' parens. Still, I think preserving parens is the right thing to do here. It also makes it possible for a client to give special meaning to, say, nested parens: Perhaps `process [| f x |]` and `process [| f ((x)) |]` will behave differently. (Idiom brackets, anyone?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15479: Return HsType GhcTc from tc_hs_type
by GHC 03 Dec '18

03 Dec '18

#15479: Return HsType GhcTc from tc_hs_type -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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 is a part of https://ghc.haskell.org/trac/ghc/wiki/Design/TypeRefactor -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15986: Poor error message source location reporting with unsaturated type family
by GHC 03 Dec '18

03 Dec '18

#15986: Poor error message source location reporting with unsaturated type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeErrors | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where newtype WrapChar f = MkWrapChar (f Char) type family F a type family T a type instance T Int = WrapChar F }}} Then you'll get this error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:15: error: • The type family ‘F’ should have 1 argument, but has been given none • In the type instance declaration for ‘T’ | 7 | type instance T Int = WrapChar F | ^ }}} The thing is, the location of that caret is rather unfocused. It's pointing at `T`, but the real culprit is `F`! I know that GHC can do better here because other error messages actually get this right. For instance, if you change the `T Int` instance to this: {{{#!hs type instance T Int = F }}} Then GHC will actually point to `F` in the resulting error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:23: error: • Expecting one more argument to ‘F’ Expected a type, but ‘F’ has kind ‘* -> *’ • In the type ‘F’ In the type instance declaration for ‘T’ | 7 | type instance T Int = F | ^ }}} If GHC can point to the right place in the source code in this situation, then it ought to get the earlier situation right as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15980: unpin a mutable byte array
by GHC 03 Dec '18

03 Dec '18

#15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Sometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it might not be useful for it to be pinned anymore. If it's a little byte array, it may contribute to a fragmented heap. Even if it's large, the fact that the user explicitly asked pin it prohibits it from ever being added to a compact region (pinned bytearrays that were pinned simply because they are over 3KB can be added to compact regions). A workaround for either of these problems is to copy the pinned bytearray into an unpinned byte array afterwards. But that's kind of wasteful. Is it possible to have a primop {{{ unpinMutableByteArray :: MutableByteArray s -> State# s -> State# s }}} After this, the mutable byte array could be moved in memory. This would require `isMutableByteArrayPinned#` to undergo a similar transition as `sizeofMutableByteArray#` (which was superceeded by `getSizeofMutableByteArray#`) underwent. Is this possible? Or are pinned things allocated in a special place that makes unpinning impossible? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15983: Built-in support for half-floats
by GHC 03 Dec '18

03 Dec '18

#15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set. It would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double. I'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 03 Dec '18

03 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T7503a Comment: I've added a test case for the first program in comment:10 as `T7503a`. A test case for the other program—which I'd assume would be called `T7503b`—must wait for another day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location
by GHC 03 Dec '18

03 Dec '18

#14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, TypeOperators, ConstraintKinds, TypeFamilies, DataKinds, TypeInType, GADTs, AllowAmbiguousTypes, InstanceSigs, RankNTypes, UndecidableInstances #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type Cat ob = ob -> ob -> Type type family Apply (f :: a ~> b) (x :: a) :: b where Apply (CompSym2 f g) a = Comp f g a data CompSym2 :: (b ~> c) -> (a ~> b) -> (a ~> c) type a·b = Apply a b class Varpi (f :: i ~> j) where type Dom (f :: i ~> j) :: Cat i type Cod (f :: i ~> j) :: Cat j varpa :: Dom f a a' -> Cod f (f·a) (f·a') type family Comp (f::k1 ~> k) (g::k2 ~> k1) (a::k2) :: k where Comp f g a = f · (Apply g a) }}} This compiles, but if I replace the final line by {{{#!hs Comp f g a = f · (g · a) }}} oddly enough I get an error message about the method `varpa`! Seemingly unrelated apart from using `(·)`: {{{ $ ghci2 hs/093-bug.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/093-bug.hs, interpreted ) hs/093-bug.hs:23:33: error: • Expected kind ‘i ~> i’, but ‘f’ has kind ‘i ~> j’ • In the first argument of ‘(·)’, namely ‘f’ In the second argument of ‘Cod’, namely ‘(f · a)’ In the type signature: varpa :: Dom f a a' -> Cod f (f · a) (f · a') | 23 | varpa :: Dom f a a' -> Cod f (f·a) (f·a') | ^ Failed, 0 modules loaded. Prelude> }}} NOW — let's randomly remove both lines that mention `CompSym2` and it mysteriously works, again! `Apply` and `(·)` seem to be equal up to variable names, I can't spot why {{{ >> :set -fprint-explicit-foralls >> :set -fprint-explicit-kinds >> :set -fprint-explicit-coercions >> >> :kind Apply Apply :: forall {a} {b}. (a ~> b) -> a -> b >> :kind (·) (·) :: forall {a} {k}. (a ~> k) -> a -> k }}} but it works if I define `(·)` as a type family rather than a synonym: {{{#!hs type family (f::a ~> b) · (x::a) :: b where f · x = Apply f x }}} so it's some difference between synonyms and TFs, but is it intentional? It's certainly odd how the error messages jumped the `varpa` method when we actually modified `Comp`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 03 Dec '18

03 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"aef5d82543bb642a65f63e1f05f245b9cddafd8c/ghc" aef5d825/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aef5d82543bb642a65f63e1f05f245b9cddafd8c" Add test cases for #7503, #14451 At some point between 8.4 and 8.6, two things were fixed: * The entirety of #14451. * One of the test cases in #7503. I've added this as T7503a. The other test case from that ticket still does /not/ work, so we'll have to add T7503b some other day. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15791: typeKind confuses Type and Constraint
by GHC 03 Dec '18

03 Dec '18

#15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- The `typeKind` function takes a type and reports its kind. It gets this wrong, sometimes: if you ask for `typeKind` of the quantified constraint `Eq a => C a` (where `C` is a class), you get `Type`. This is wrong, though I don't have a concrete case where GHC misfires. We ''could'' fix `typeKind` to get this right, but doing so would require making the `FunTy` case recursive (right now, it always returns `Type`). This is wasteful, because most clients of `typeKind` do not care about the distinction between `Type` and `Constraint`. Instead, I propose making a new `tcTypeKind` which behaves correctly in this case. We could also muse about making `tcTypeKind` monadic so that it can look through unification variables. This might also simplify the story around `Note [The tcType invariant]`. Regardless of the "make monadic" idea, I claim that, when this is done, we should have `isPredTy` be functionally equivalent to `(== Constraint) . tcTypeKind`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13256: Warn on out-of-range literals in pattern matches too
by GHC 03 Dec '18

03 Dec '18

#13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- We have these nice warnings for numeric literal expressions that are out of range of their type: {{{ Prelude> 100000000000000000000000000000000 :: Int <interactive>:1:1: warning: [-Woverflowed-literals] Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807 }}} but nothing for numeric patterns: {{{ Prelude> (\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int <interactive>:3:8: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: p where p is not one of {100000000000000000000000000000000} *** Exception: <interactive>:3:8-64: Non-exhaustive patterns in case }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3