- ghc-tickets - Haskell.org

[GHC] #13398: Associated type family instance validity checking is too conservative
by GHC 15 Mar '17

15 Mar '17

#13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: #11450 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `mediabus-0.3.0.1` currently fails to build on GHC HEAD because of this regression. Here's a simplified program which exemplifies the issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' }}} This compiles fine on GHC 8.0.2, but on GHC HEAD, it gives an odd error: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170307: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Mediabus ( Bug.hs, interpreted ) Bug.hs:19:8: error: • Polymorphic type indexes of associated type ‘SetStaticDuration’ (i.e. ones independent of the class type variables) must be distinct type variables Expected: SetStaticDuration (t :/ r) <tv> Actual: SetStaticDuration (t :/ r) (t' :/ r') where the `<tv>' arguments are type variables, distinct from each other and from the instance variables • In the type instance declaration for ‘SetStaticDuration’ In the instance declaration for ‘HasStaticDuration (t :/ r)’ | 19 | type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This error message comes from 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450). To fix it, you have to do a tiresome song and dance with auxiliary type families: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) pt = SSDTicks pt type family SSDTicks (pt :: StaticTicks) :: StaticTicks where SSDTicks (t' :/ r') = t' :/ r' }}} But after Simon's motivation for this change in https://ghc.haskell.org/trac/ghc/ticket/11450#comment:24, I'm still not convinced that the original program should be rejected. After all, this change was introduced so that associated type families with //multiple// would be rejected. But in the `SetStaticDuration` example above, there's only one equation, and it's a complete pattern match! So I'm failing to see why it should be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule
by GHC 15 Mar '17

15 Mar '17

#13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Roboguy reports (via IRC) that the following causes a GHC panic: {{{#!hs {-# LANGUAGE RankNTypes #-} module Crash where data Exp a = Exp fromExp :: Exp a -> a fromExp _ = error "Impossible" toExp :: a -> Exp a toExp _ = Exp newtype Iter a b = Iter { getIter :: forall r. (a -> r) -> (b -> r) -> r } iterLoop :: (a -> Iter a b) -> a -> b iterLoop f x = getIter (f x) (iterLoop f) id -- This rewrite rule results in a GHC panic: "opt_univ fell into a hole" on GHC 8.0.1, 8.0.2, and 8.1. {-# RULES "fromExp-into-iterLoop" [~] forall (f :: Int -> Iter (Exp Int) (Exp Char)) (init :: Int). fromExp (iterLoop f init) = fromExp (iterLoop (f . fromExp) (toExp init)) #-} }}} I have confirmed this, and see the following error: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170305 for x86_64-unknown-linux): opt_univ fell into a hole {a1WD} Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:398:29 in ghc:OptCoercion }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 15 Mar '17

15 Mar '17

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13423: Exception to I/O hack in demand analyzer too broad
by GHC 15 Mar '17

15 Mar '17

#13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The I/O hack in the demand analyzer triggers only for expressions that are not direct applications of primops (see `io_hack_reqd` in `stranal/DmdAnal.hs`). This seems rather arbitrary, and can produce surprising results. Consider {{{#!hs fish :: Int -> IORef Int -> IORef Int -> IO () fish n ref next = do writeIORef ref n writeIORef next n x <- getLine case readMaybe x of Just True -> fish (n + 1) ref next _ -> pure () }}} If `next` is bottom, I would expect this to write `n` to `ref` and then throw an exception. But we actually get something else. First, the demand signature for `fish` ends up being `Str=<L,U(U)><S(S),1*U(U)><S(S),1*U(U)><S,U>`, which seems wrong. Then, as a result, worker/wrapper produces a wrapper that immediately unboxes both `IORef`s, so this is operationally wrong. Why do I think this is wrong? The story Haskell users are told, over and over, is that evaluation is driven only by execution; that we never force anything unless we need its value to determine the next `IO` action. That principle is violated here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13427: Per-function code-generation options
by GHC 15 Mar '17

15 Mar '17

#13427: Per-function code-generation options -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- On ghc-devs Ed Kmett has [[https://mail.haskell.org/pipermail/ghc- devs/2017-March/013923.html|asked]] for some way to more precisely specify code generation options (e.g. should AVX be used?). This idea has taken a few different shapes in the thread, but I suspect that the most sensible approach is add something like a `TARGET` pragma, which the user could attach to a top-level binding. Since the interactions with inlining are non-trivial, I suspect you would want to require that this only be applied to `NOINLINE` bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13396: thread blocked when running `deepseq` with infinite list
by GHC 15 Mar '17

15 Mar '17

#13396: thread blocked when running `deepseq` with infinite list -------------------------------------+------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: thread | Operating System: Unknown/Multiple blocked | Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs ghci> :m +Control.Deepseq ghci> let x = [1..] ghci> x `deepseq` () Ctrl^C Interrupted. ghci> ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11450: Associated types at wrong type in instance
by GHC 14 Mar '17

14 Mar '17

#11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- Consider {{{ class C x where type T x instance C (Either a b) where type T (Either b a) = b -> a }}} This is bogus, because the equation for `T` has the parameters to `Either` reversed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13405: Reimplement unsafeInterleaveIO using runRW#
by GHC 14 Mar '17

14 Mar '17

#13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- Currently, we have {{{#!hs {-# INLINE unsafeInterleaveIO #-} unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) {-# NOINLINE unsafeDupableInterleaveIO #-} unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO ( \ s -> let r = case m s of (# _, res #) -> res in (# s, r #)) }}} This all seems a bit weird from a semantic standpoint, and also seems likely to get in the way of the best idea I have so for for converting precise exceptions to imprecise ones in unsafe functions. === The substantial semantic weirdness === `unsafeDupableInterleaveIO` takes the current state of the world, `s`, and passes it to `m`. But it passes it to `m` at some time when the actual real world has most likely moved on! That is, we pass `m` a moment of the ''past''. Strange indeed. === The exception handling matter === I would like to separate precise exceptions (thrown using `raiseIO#`) from imprecise ones (thrown using `raise#`). In particular, I want to offer an operation that catches only precise exceptions. But `unsafePerformIO` and `unsafeInterleaveIO` and such need to convert precise exceptions into imprecise ones to avoid breaking the more aggressive demand analysis of the hypothetical `catchThrowIO`. === The fix === I believe the fix is pretty simple: rather than holding a piece of the past in our pocket, start a new timeline: {{{#!hs unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO (\ s -> (# s, runRW# (\s2 -> case m s2 of (# _, res #) -> res) #)) }}} This seems to me to get the point across a lot better, and it ''may'' even allow us to remove the `NOINLINE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3207: readMutVar# is inlined/duplicated
by GHC 14 Mar '17

14 Mar '17

#3207: readMutVar# is inlined/duplicated -------------------------------------+------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | codeGen/should_run/3207 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This was closed by commit 8a3ed3364fbc74b1f1b87b049737da2b251f92df, which made a slew of "I/O-like" primops `has-side-effects`, even though they were "read-only". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3207#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13421: Confusing error when using BangPatterns without pragma
by GHC 14 Mar '17

14 Mar '17

#13421: Confusing error when using BangPatterns without pragma -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you have something like this {{{ putTagType :: TagType -> Put putTagType !x = putWord8 $! fromIntegral $! fromEnum x {-# INLINE putTagType #-} }}} and forget to put the pragma for BangPatterns you get this: {{{ /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:40:1: error: The type signature for ‘putTagType’ lacks an accompanying binding /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:42:12: error: The INLINE pragma for ‘putTagType’ lacks an accompanying binding Warning: File listed in mineserver-nbt/mineserver-nbt.cabal file does not exist: README.md }}} which leaves you very confused thinking you made a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1