November 2018 - ghc-tickets

[GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket
by GHC 01 Feb '19

01 Feb '19

#15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- == Current behavior == An old ticket link is redirected to this new site, just not to the actual ticket, so some form of redirection is configured: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || == Desired outcome == An old ticket link should redirect to the actual ticket: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #15632: Undependable Dependencies
by GHC 30 Jan '19

30 Jan '19

#15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: | Operating System: Unknown/Multiple FunctionalDependencies, | OverlappingInstances | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10675 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, GADTs, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} data Hither = Hither deriving (Eq, Show, Read) -- just three data Thither = Thither deriving (Eq, Show, Read) -- distinct data Yon = Yon deriving (Eq, Show, Read) -- types class Whither a b | a -> b where whither :: a -> b -> b -- instance Whither Int Hither where -- rejected: FunDep conflict -- whither _ y = y -- with Thither instance, so instance {-# OVERLAPPING #-} (b ~ Hither) => Whither Int b where whither _ y = y instance {-# OVERLAPS #-} Whither a Thither where whither _ y = y instance {-# OVERLAPPABLE #-} (b ~ Yon) => Whither a b where whither _ y = y f :: Whither Int b => Int -> b -> b f = whither g :: Whither Bool b => Bool -> b -> b g = whither }}} Should those three instances be accepted together? In particular, the published work on FDs (including the FDs through CHRs paper) says the `Thither` instance should behave as if: {{{#!hs instance (beta ~ Thither) => Whither a beta where ... }}} (in which `beta` is a unification variable and the `~` constraint is type improvement under the FD.) But now the instance head is the same as the `Yon` instance, modulo alpha renaming; with the constraints being contrary. That's demonstrated by the inferred/improved type for `g`: {{{#!hs *Whither> :t g ===> g :: Bool -> Thither -> Thither -- and yet *Whither> g True Yon ===> Yon }}} What do I expect here? * At least the `Thither` and `Yon` instances to be rejected as inconsistent under the FunDep. * (The `Hither` instance is also inconsistent, going by the strict interpretation in published work. But GHC's rule here is bogus, as documented in Trac #10675.) Exploiting Overlapping instances is essential to making this go wrong. The published work shies away from considering `FunDeps + Overlap`; and yet specifying the semantics as if the instances used bare unification variables is almost inevitably going give overlaps -- especially if there are multiple FDs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15632> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #15970: Recompilation bug with default class methods
by GHC 28 Jan '19

28 Jan '19

#15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Repro as follows. A.hs: {{{ {-# OPTIONS_GHC -fno-full-laziness #-} module A (toTypedData, toTypedDataNoDef) where toTypedData :: String -> IO Int toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s wrapPrint :: String -> IO Int -> IO Int wrapPrint s act = do putStrLn s act toTypedDataNoDef :: String -> IO Int toTypedDataNoDef s = return $ length s }}} B.hs: {{{ module B ( TypeClass(..) ) where import A class Show a => TypeClass a where getSize :: a -> IO Int getSize a = toTypedData (show a) printA :: a -> IO () }}} C.hs: {{{ module Main where import B data MyDataType = MyDataType String Int deriving Show instance TypeClass MyDataType where printA = putStrLn . show main :: IO () main = do let myValue = MyDataType "haha" 99 sz <- getSize myValue putStrLn $ show sz printA myValue }}} 1. Comment out the `-fno-full-laziness` option in A.hs 2. `rm *.o *.hi; ghc -O2 C.hs` 3. Re-enable the `-fno-full-laziness` option in A.hs 4. `ghc -O2 C.hs` Produces a linker error: {{{ C.o:Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data.rel.ro+0x48): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status }}} Reproduced in 8.0, 8.4 and master. Probably happens in all released versions of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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

[GHC] #13512: GHC incorrectly warns that a variable used in a type application is unused
by GHC 27 Jan '19

27 Jan '19

#13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug is reproducible on GHC 8.0.1, 8.0.2, 8.2, and HEAD. {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wunused-foralls #-} module Bug where import Data.Proxy proxy :: forall k (a :: k). Proxy a proxy = Proxy data SomeProxy where SomeProxy :: forall k (a :: k). Proxy a -> SomeProxy someProxy :: forall k (a :: k). SomeProxy someProxy = SomeProxy (proxy @k @a) }}} {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170327: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:23: warning: [-Wunused-foralls] Unused quantified type variable ‘(a :: k)’ In the type ‘forall k (a :: k). SomeProxy’ | 17 | someProxy :: forall k (a :: k). SomeProxy | ^^^^^^^^ Ok, modules loaded: Bug. }}} But that `a` is used in `proxy @k @a`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9