October 2017 - ghc-tickets

[GHC] #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’
by GHC 04 Jun '18

04 Jun '18

#14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This {{{#!hs newtype M m a = M (m a) deriving newtype Functor }}} produces something similar to {{{#!hs instance Functor m => Functor (M m) where fmap :: forall a a'. (a -> a') -> (M m a -> M m a') fmap = coerce (fmap @m @a @a') }}} but as wiki:Roles2 points out, this fails for methods such as `join_`: {{{#!hs class MonadJoin m where join_ :: m (m a) -> m a newtype M m a = M (m a) deriving newtype MonadJoin -- Couldn't match representation of type ‘m (M m a)’ with that of ‘m (m a)’ }}} I think the user should be given the option to respect the roles or not by supplying `unsafe` wiki:Commentary/Compiler/DerivingStrategies {{{#!hs newtype M m a = M (m a) deriving unsafe newtype MonadJoin -- -( Produces `unsafeCoerce' instead of `coerce' )- -- instance MonadJoin m => MonadJoin (M m) where -- join_ :: forall a. M m (M m a) -> M m a -- join_ = unsafeCoerce (join_ @m @a) }}} This lets us (`newtype`-) derive a host of instances that we currently can not: `Traversable`, `Distributive` (currently forbidden due to [https://hackage.haskell.org/package/distributive-0.5.2/docs/Data- Distributive.html#v:distribute distribute]), [https://hackage.haskell.org/package/linear-1.20.7/docs/Linear- Matrix.html#v:trace Trace], [http://hackage.haskell.org/package/profunctors-5/docs/Data-Profunctor- Monad.html ProfunctorMonad / ProfunctorComonad], ... It does not seem like lenses (`FunctorWithIndex`, `FoldableWithIndex`, `TraversableWithIndex`) work with this though -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14317: Solve Coercible constraints over type constructors
by GHC 04 Jun '18

04 Jun '18

#14317: Solve Coercible constraints over type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- The core question is, could `fails` type check? {{{#!hs import Data.Type.Coercion works :: Identity a `Coercion` Compose Identity Identity a works = Coercion -- • Couldn't match representation of type ‘Identity’ -- with that of ‘Compose Identity Identity’ -- arising from a use of ‘Coercion’ -- • In the expression: -- Coercion :: Identity `Coercion` Compose Identity Identity fails :: Identity `Coercion` Compose Identity Identity fails = Coercion }}} ---- This arises from playing with [https://duplode.github.io/posts/traversable-a-remix.html Traversable: A Remix]. Given `coerce :: Compose Identity Identity ~> Identity` I wanted to capture that `id1` and `id2` are actually the same arrow (up to representation) {{{#!hs (<%<) :: (Functor f, Functor g) => (b -> g c) -> (a -> f b) -> (a -> Compose f g c) g <%< f = Compose . fmap g . f id1 :: a -> Identity a id1 = Identity id2 :: a -> Compose Identity Identity a id2 = Identity <%< Identity }}} So I define {{{#!hs data F :: (k -> Type) -> (Type -> k -> Type) where MkF :: Coercible f f' => (a -> f' b) -> F f a b id1F :: Coercible Identity f => F f a a id1F = MkF id1 id2F :: Coercible (Compose Identity Identity) f => F f b b id2F = MkF id2 }}} but we can not unify the types of `id1F` and `id2F`. Does this require quantified class constraints? I'm not sure where they would go -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12152: panic: Loading temp shared object failed
by GHC 03 Jun '18

03 Jun '18

#12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've attached a no-Haskell-code project that fails when I run `cabal repl` with the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc60744_0/libghc_1.so: undefined symbol: _ZN2Zq1qE }}} Building the project works fine, so the problem seems to be (only) with dynamic linking. The issue can be resolved by swapping the order of the .cpp files in the cabal file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness?
by GHC 03 Jun '18

03 Jun '18

#11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #14059: COMPLETE sets don't work at all with data family instances
by GHC 03 Jun '18

03 Jun '18

#14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code that uses a pattern synonym for a data family GADT constructor, along with a corresponding `COMPLETE` set: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data family Sing (a :: k) data instance Sing (z :: Bool) where SFalse :: Sing False STrue :: Sing True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => Sing z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: Sing (z :: Bool) -> Bool wibble STrue = True wobble :: Sing (z :: Bool) -> Bool wobble STooGoodToBeTrue = True }}} However, if you compile this, you might be surprised to find out that GHC only warns about `wibble` being non-exhaustive: {{{ $ 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:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 23 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ }}} I believe the use of data families is the culprit here, since a variant of this program which doesn't use data families correctly warns for both `wibble` and `wobble`: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Foo where data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: SBool z -> Bool wibble STrue = True wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:20:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 20 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Foo.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: SFalse | 23 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13777: Poor error message around CUSKs
by GHC 03 Jun '18

03 Jun '18

#13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: TypeInType, | Operating System: Unknown/Multiple CUSKs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While typing up comment:7:ticket:13761, I came across a poor error message around CUSKs. {{{ data Proxy (a :: k) = P data S :: forall k. Proxy k -> Type where MkS :: S (P :: Proxy Maybe) }}} produces {{{ You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: }}} That promised list of the kinds of user-written variables is empty. Either GHC should find something to print (like `k :: k0`, perhaps) or omit the header. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14324: Consider deprecating STM invariant mechanism
by GHC 03 Jun '18

03 Jun '18

#14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- fryguybob and I were recently discussing the STM invariant mechanism. This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that the implementation currently takes so many locks that it very likely prevents these odd interleavings from occurring. In addition, * the implementation doesn't handle nested STM invariants correctly (#7930) * the locking behavior of the implementation was, until very recently, utterly wrong (#14310) * the feature introduces quite a bit of complexity in the RTS * the interface has essentially no users, as evidenced by a Hackage search and the fact that #14310 went unnoticed for years All of this raises the question: Is the STM invariants feature really where we want to spend our complexity budget? Perhaps it is time for this feature to quietly pass (after an appropriate deprecation period, of course). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14310: Assertion triggered by STM invariant.
by GHC 02 Jun '18

02 Jun '18

#14310: Assertion triggered by STM invariant. --------------------------------------+---------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: --------------------------------------+---------------------------------- The program attached depends on the async and stm packages. It will push some numbers through a pipeline, while keeping track of some state. If invoked without arguments, the program will output the state and result of each iteration. If invoked via "./repro check", an STM invariant will be installed when the state is initialized. This invariant will cause the program to a) hangup, presumably due to a livelock, if the program has been compiled without "-debug", b) crash with the following error: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 1001", if the "-debug" flag has been used for compilation. The latter case also happens with GHC 8.0.2: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 997". Furthermore, this problem only occurs if the program is compiled using the additional flags "-rtsopts -threaded -with-rtsopts=-N". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage
by GHC 02 Jun '18

02 Jun '18

#12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This seems to be a build regression from ghc-8.0.1. The ghc.1 manpage was not installed for the 8.0.2 RC1 build. I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8