July 2018 - ghc-tickets

[GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC
by GHC 03 Feb '19

03 Feb '19

#9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- First, load the following program into GHCi. '''Fun.hs''' {{{#!hs module Fun where import Language.Haskell.TH stuff = do -- let x = mkName "X" x <- newName "X" sequence $ [dataD (return []) x [] [ normalC x [] ] []] }}} '''thbug.hs''' {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Fun stuff }}} Then comment out the newName, un comment the mkName and reload GHCi. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): kcLookupKind APromotionErr RecDataConPE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is important to note this is a valid program, if you then close GHCi and start it again with the modified file, it will load correctly. Reloading after attempting to compile the newName version will cause a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11084: Some type families don't reduce with :kind!
by GHC 03 Feb '19

03 Feb '19

#11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sadly, I'm unable to reproduce this without `singletons`. :( Observe: {{{ > ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Promotion.Prelude -- singletons-2.0.1 Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = Data.Singletons.Prelude.List.Case_1628035408 'True 'True 'True '[] (Data.Singletons.Apply (Data.Singletons.Apply (:==$) 'True) 'True) Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = JustSym1 'True }}} Note that the exact same command run twice yields different results. I tried peeking at `-ddump-tc-trace` but got nothing of use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12001: RFC: Add pattern synonyms to base
by GHC 02 Feb '19

02 Feb '19

#12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | 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: -------------------------------------+------------------------------------- Since we have pattern synonyms it's worth considering if some belong in base: [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex-Lens.html Data.Complex.Lens] contains patterns that could be defined in base, here are some more suggestions: === Data.Array === {{{#!hs pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> (low'high, xs)) where ArrayIx low'high xs = array low'high xs }}} === Data.Bits === {{{#!hs pattern ZeroBits :: (Eq a, Bits a) => a pattern ZeroBits <- ((== zeroBits) -> True) where ZeroBits = zeroBits pattern BitSize :: Bits a => Int -> a pattern BitSize n <- (bitSizeMaybe -> Just n) pattern Signed :: Bits a => a pattern Signed <- (isSigned -> True) pattern Unsigned :: Bits a => a pattern Unsigned <- (isSigned -> False) pattern PopCount :: Bits a => Int -> a pattern PopCount n <- (popCount -> n) }}} === Data.Char === {{{#!hs pattern ControlChar :: Char pattern ControlChar <- (isControl -> True) pattern SpaceChar :: Char pattern SpaceChar <- (isSpace -> True) }}} === Data.Complex === {{{#!hs pattern Conjugate :: Num a => Complex a -> Complex a pattern Conjugate a <- (conjugate -> a) where Conjugate a = conjugate a pattern Polar :: RealFloat a => a -> a -> Complex a pattern Polar m theta <- (polar -> (m, theta)) where Polar m theta = mkPolar m theta -- See https://github.com/ekmett/lens/issues/653 pattern Real :: Num a => a -> Complex a pattern Real r <- r :+ _ where Real r = r :+ 0 pattern Imaginary :: Num a => a -> Complex a pattern Imaginary i <- _ :+ i where Imaginary i = 0 :+ i }}} === GHC.Float === {{{#!hs pattern NegativeZero :: RealFloat a => a pattern NegativeZero <- (isNegativeZero -> True) where NegativeZero = -0 pattern Denormalized :: RealFloat a => a pattern Denormalized <- (isDenormalized -> True) pattern NaN :: RealFloat a => a pattern NaN <- (isNaN -> True) where NaN = 0 / 0 -- How ever negative infinity is handled pattern Infinity :: RealFloat a => a pattern Infinity <- ((== 1 / 0) -> True) where Infinity = 1 / 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11004: hsc2hs does not handle single quotes properly
by GHC 01 Feb '19

01 Feb '19

#11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.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: -------------------------------------+------------------------------------- The tool gets confused by quotes for promoted constructors (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/promotion.h… #promotion-syntax). Here's an example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} gets translated into {{{#!hs {-# LINE 1 "Test.hsc" #-} {-# LANGUAGE DataKinds #-} {-# LINE 2 "Test.hsc" #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} Then GHC complains about `#size`: {{{ Test.hsc:10:16: parse error on input ‘#’ }}} Judging from the source of utils/hsc2hs/HSCParser.hs, the tool treats single quotes the same way as double quotes. I.e. it looks for balanced, possibly multiline, strings delimited by '. At least, it seems unnecessary to expect newlines in that string-like structure, because character literals cannot contain newlines, AFAIK. It's interesting to note that this problem looks like a bit of an edge case, since highlighting in the ticket seems to be confused as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13834: Error cascade with type applications
by GHC 01 Feb '19

01 Feb '19

#13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer, | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using type applications with an out of scope identifier causes an unfortunate error cascade. {{{ foo = notInScope @Bool }}} Leads to the right out of scope error but also an error about using type application when `notInScope` is not a polytype. I think the second error should be suppressed. {{{ t.hs:4:7: error: Variable not in scope: notInScope | 4 | foo = notInScope @Bool | ^^^^^^^^^^ t.hs:4:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ notInScope • In the expression: notInScope @Bool In an equation for ‘foo’: foo = notInScope @Bool | 4 | foo = notInScope @Bool | ^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11222: Teach strictness analysis about `catch`-like operations
by GHC 31 Jan '19

31 Jan '19

#11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Consider the `catch#` primop, {{{#!hs catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -- ^ thing to catch exceptions from -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -- ^ exception handler -> State# RealWorld -> (# State# RealWorld, a #) }}} Semantically, this operation will always evaluate its first argument. Ideally we would indicate this in the primop's strictness signature in `primops.txt.pp`. Sadly, we can't do this at the moment due to a subtle wrinkle (discovered in #10712): Consider, {{{#!hs let r = \st -> raiseIO# blah st in catch (\st -> ...(r st)..) handler st }}} If we give the first argument of catch a strict signature, we'll get a demand `C(S)` for `r`; that is, `r` is definitely called with one argument, which indeed it is. The trouble comes when we feed `C(S)` into `r`'s RHS as the demand of the body as this will lead us to conclude that the whole `let` will diverge; clearly this isn't right. As Simon noted in ticket:10712#comment:4, > There's something very special about catch: it turns divergence into non-divergence. In order to apply a proper strictness signature to `catch`-like operations we would need to teach the strictness analyzer about this property. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14998: Sort out the strictness mess for exceptions
by GHC 31 Jan '19

31 Jan '19

#14998: Sort out the strictness mess for exceptions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Over time we have evolved into a messy and bad place for the interaction of strictness analysis and exceptions. Here's the amazing history of the strictness of `catch#` * Dec 13: 0558911f91c: catch# gets a strictness signature with `lazyApply1Dmd` * Jul 15: 7c0fff41789: catch# goes from `lazyApply1Dmd` to `strictApply1Dmd` * Dec 15: 28638dfe79e: catch# goes from `strictApply1Dmd` to `lazyApply1Dmd`. Trac #10712 * Jan 16: 9915b656440: catch# goes from `lazyApply1Dmd` to `catchArgDmd`, and result goes from `botRes` to `exnRes` Trac #11222. * Mar 17: 701256df88c: catch# goes from 'catchArgDmd` to `lazyApply1Dmd`. This ticket #13330. See also * `Note [Strictness for mask/unmask/catch]` in `primops.txt/pp`. * `exceptions_and_strictness` in `primops.txt/pp`. * `Note [Exceptions and strictness]` in `Demand.hs` * #11555, #13330, #10712, #11222 '''Item 1: ThrowsExn''' * The strictness analyser has quite a bit of complexity around `ThrowsExn`. * `ThrowsExn` only differs from `Diverges` if the `ExnStr` flag is set to `ExnStr` * And the only place that happens is in `Demand.catchArgDmd` * The only place `catchArgDmd` is used is in `primops.txt.pp`. Originally, in the patch for #11222, `catchArgDmd` was used for the first arg of `catch#`, `catchSTM#` and `catchRetry#`. * But the patch in this ticket removed two of those three; now only `catchRetry#` uses the `catchArgDmd` thing. It looks to me as if `catchRetry#` was left out by mistake; and indeed David says "I left it out on the grounds that I didn't understand it well enough." And if so, that's the last use of `catchArgDmd` and I think that all the tricky `ThrowsExn` machinery can disappear. '''Item 2: strictness of catchException''' As a result of all this to-and-fro we have in GHC.IO {{{ catch (IO io) handler = IO $ catch# io handler' catchException !io handler = catch io handler }}} That is, `catchException` is strict in the IO action itself. But Neil argues in #11555, commment:6 that this is bad because it breaks the monad laws. I believe that there is some claimed performance gain from the strictness of `catchException`, but I don't believe it exists. The perf gain was from when it had a `strictApply1Dmd`; that is, it promised to call its argument. See this note in `primops.txt.pp` {{{ -- Note [Strictness for mask/unmask/catch] -- Consider this example, which comes from GHC.IO.Handle.Internals: -- wantReadableHandle3 f ma b st -- = case ... of -- DEFAULT -> case ma of MVar a -> ... -- 0# -> maskAsynchExceptions# (\st -> case ma of MVar a -> ...) -- The outer case just decides whether to mask exceptions, but we don't want -- thereby to hide the strictness in 'ma'! Hence the use of strictApply1Dmd. }}} I think the above saga was all in pursuit of exposing the strictness of `ma` if we used `catch#` instead of `maskAsynchExceptions#` in this example. But the saga ultimate appears to have failed, and the strictenss annotation in `catchException` is a vestige that carries no benefit, but does requires comments etc. '''Item 3: performance''' If making `catch#` have strictness `strictApply1Dmd` improves perf, it would be good to know where. That would entail making the (tiny) change, recompiling all, and nofibbing. Here is the commit message in 7c0fff41789, which added `strictApply1Dmd`: {{{ commit 7c0fff41789669450b02dc1db7f5d7babba5dee6 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jul 21 12:28:42 2015 +0100 Improve strictness analysis for exceptions Two things here: * For exceptions-catching primops like catch#, we know that the main argument function will be called, so we can use strictApply1Dmd, rather than lazy Changes in primops.txt.pp * When a 'case' scrutinises a I/O-performing primop, the Note [IO hack in the demand analyser] was throwing away all strictness from the code that followed. I found that this was causing quite a bit of unnecessary reboxing in the (heavily used) function GHC.IO.Handle.Internals.wantReadableHandle So this patch prevents the hack applying when the case scrutinises a primop. See the revised Note [IO hack in the demand analyser] Thse two things buy us quite a lot in programs that do a lot of IO. Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg -0.4% -2.9% -0.9% -1.0% +0.0% reverse-complem -0.4% -10.9% +10.7% +10.9% +0.0% simple -0.3% -0.0% +26.2% +26.2% +3.7% sphere -0.3% -6.3% 0.09 0.09 +0.0% -------------------------------------------------------------------------------- Min -0.7% -10.9% -4.6% -4.7% -1.7% Max -0.2% +0.0% +26.2% +26.2% +6.5% Geometric Mean -0.4% -0.3% +2.1% +2.1% +0.1% }}} If these gains are still on the table (i.e. moving to `strictApply1Dmd` gives them), perhaps we can add some strictness annotations to the I/O to replicate the effect, even if we'd decided we can't actualy make `catch#` strict? '''Item 4: IO hack in the demand analyser''' In getting up to speed with this, I noticed this comment in the demand analyser: {{{ {- Note [IO hack in the demand analyser] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's a hack here for I/O operations. Consider case foo x s of { (# s', r #) -> y } ...omitted... However, consider f x s = case getMaskingState# s of (# s, r #) -> case x of I# x2 -> ... Here it is terribly sad to make 'f' lazy in 's'. After all, getMaskingState# is not going to diverge or throw an exception! This situation actually arises in GHC.IO.Handle.Internals.wantReadableHandle (on an MVar not an Int), and made a material difference. So if the scrutinee is a primop call, we *don't* apply the state hack... }}} Idea: in the nested-CPR work, we have simple termination information. So we can use that, instead of "is a primop call" to deliver on this hack in a much more principled way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #12092: Wrong error message with TypeApplications
by GHC 31 Jan '19

31 Jan '19

#12092: Wrong error message with TypeApplications -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I write the following: {{{#!hs {-# language TypeApplications #-} module Bug where huh = spam @Int }}} I expect to get the error: {{{ • Variable not in scope: spam • Perhaps you meant ‘span’ (imported from Prelude) }}} But instead, I get the error: {{{ • Cannot apply expression of type ‘t0’ to a visible type argument ‘Int’ • In the expression: spam @Int In an equation for ‘huh’: huh = spam @Int }}} While it is //technically// true that I cannot apply an out-of-scope identifier to a visible type argument, this is probably the less useful error to receive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15320: Save the types in the typechecked syntax tree
by GHC 30 Jan '19

30 Jan '19

#15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types). I found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help. The type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly. It could be implemented nicely by adding type information to the `X* GhcTc` type families. I plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12758: Bring sanity to our performance testsuite
by GHC 28 Jan '19

28 Jan '19

#12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | 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 GHC testsuite's performance tests tends to be a constant source of busy-work as it requires that contributors manually bump performance numbers and propagate these changes across platforms. Moreover, the testsuite is poor at noticing performance regressions due to false positive failures (due to spurious environmental differences) and false negatives (due to the rather generous acceptance windows that many tests have). Joachim and I briefly discussed this at Hac Phi and came up with the following proposal: * We rip expected performance numbers out of the `.T` files * -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20