November 2018 - ghc-tickets

[GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints
by GHC 04 Dec '18

04 Dec '18

#14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Add an error message to the compiler when ApplicativeDo desugaring: * requires a Monad constraint when a Functor/Applicative constraint is expected * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{#!hs ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

04 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 04 Dec '18

04 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] #15980: unpin a mutable byte array
by GHC 04 Dec '18

04 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] #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

[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

[GHC] #10930: missing empty-Enumeration warning for `Natural`
by GHC 03 Dec '18

03 Dec '18

#10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7881, #10929 Differential Rev(s): | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in
by GHC 03 Dec '18

03 Dec '18

#15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts this program: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type KindOf (a :: k) = k type A a = (Any :: a) type KA = KindOf A }}} But it really oughtn't to. After all, we have an unsaturated use of `A` in `KindOf A`, and we don't have `LiberalTypeSynonyms` enabled! What's even stranger is that there seems to be something about this exact setup that sneaks by `LiberalTypeSynonyms`' validity checks. If I add another argument to `A`: {{{#!hs type A x a = (Any :: a) }}} Then it //does// error: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:1: error: • Illegal polymorphic type: forall a -> a Perhaps you intended to use LiberalTypeSynonyms • In the type synonym declaration for ‘KA’ | 10 | type KA = KindOf A | ^^^^^^^^^^^^^^^^^^ }}} Similarly, if I use something besides `KindOf`: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type A a = (Any :: a) type B a = Int type C = B A }}} Then I also get the same `Illegal polymorphic type: forall a -> a` error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals
by GHC 03 Dec '18

03 Dec '18

#9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7