March 2018 - ghc-tickets

[GHC] #13845: Runtime linker too eagerly checks for symbol names
by GHC 04 Apr '18

04 Apr '18

#13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- I discovered this bug in https://github.com/haskell- foundation/foundation/issues/326. Take this file: {{{#!hs module Main (main) where foreign import ccall "notAThing" notAThing :: IO () main :: IO () main = putStrLn "Hello, World!" }}} Compiling and running this file works without issue. But if you try to use the runtime linker, things go haywire: {{{ $ C:\Users\RyanGlScott\Software\ghc\inplace\bin\runghc Bug.hs ghc-stage2.exe: ^^ Could not load 'notAThing', dependency unresolved. See top entry above. Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: notAThing This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} This isn't just limited to Windows, since the same thing happens on Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13330: forkIO has inconsistent behavior under optimization
by GHC 04 Apr '18

04 Apr '18

#13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Troubleshooting the T4030 failure in SimonPJ's early-inline branch, Reid and I discovered that the problem showed up when the argument to `forkIO` was obviously bottom. He came up with a tiny test case that fails without Simon's changes: {{{#!hs main = forkIO undefined >> threadDelay 1000000 }}} It looks like the trouble is in the definition of `forkIO`: {{{#!hs forkIO :: IO () -> IO ThreadId forkIO action = IO $ \ s -> case (fork# action_plus s) of (# s1, tid #) -> (# s1, ThreadId tid #) where action_plus = catchException action childHandler }}} This seems to run into the trouble with `catchException` and strictness explained in `GHC.IO`. It would appear that the conservative fix would be to replace `catchException` with `catch`. Personally, I find it a bit surprising that `forkIO` doesn't force its `IO` argument before forking, but changing that behavior could break working code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14965: GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails
by GHC 03 Apr '18

03 Apr '18

#14965: GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error. See attached files. In one file I declared: {{{#!hs module Sep where data Sep = Sep { bugVanishesWithoutThis :: [()] , middle :: [String] , orThis :: [()] } catSep :: Sep -> Sep -> Sep catSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z) cc :: Sep -> Bool cc boost = elem "foo" $ middle boost }}} and in a second file, simple code fails when compiled with -O: {{{#!hs module Main (main) where import Sep main :: IO () main = print $ cc bb bb :: Sep bb = catSep b1 b2 b1 :: Sep b1 = Sep [] ["foo"] [] b2 :: Sep b2 = Sep [] ["bar"] [] }}} This should print "True", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints "False" for GHC 8.4.1 with -O. I was unable to reproduce the bug with a single file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10016: UNPACK support for existentials
by GHC 03 Apr '18

03 Apr '18

#10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ data Foo = forall a. Show a => Foo !a !a data Bar = Bar {-# UNPACK #-} !Foo }}} The UNPACK pragma should really be able to unpack the `Foo` field, so that (implementation-wise) it would be as if you'd declared `Bar` thus: {{{ data Bar = forall a. Show a => Bar !a !a }}} But currently we get {{{ Ignoring unusable UNPACK pragma on the first argument of ‘Bar’ }}} Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- haskell-users/2015-January/025590.html here]. Vaguely related tickets: #7647, #9214. But unlike those ones, this one looks quite feasible to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14766: Hole-y partial type signatures greatly slow down compile times
by GHC 03 Apr '18

03 Apr '18

#14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This time, I actually mean it. :) Originally reported [https://github.com/simonmar/happy/issues/109 here], I distilled the example from [https://github.com/simonmar/happy/issues/109#issuecomment-362957245 this comment] into a one file test case. `Sigs.hs` is exactly like `NoSigs.hs`, except for the fact that it has a bunch of extra type signatures that have a lot of holes. On my machine, this is what compilation times are (I gave up timing after 15 minutes): || GHC version || 8.0.2 || 8.2.1 || 8.4.1 (445554b6d9a2263f969e25bb9f532dd0c3a9dc8c) || || `NoSigs.hs` || 24.13s || 22.93s || 34.05s || || `Sigs.hs` || >15m || >15m || >15m || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14643: Partial type signatures in spliced TH declarations behave unexpectedly
by GHC 03 Apr '18

03 Apr '18

#14643: Partial type signatures in spliced TH declarations behave unexpectedly -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Minimal example: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE TemplateHaskell #-} module Minimal where id [d| f :: (Monad m, _) => [m a] -> m [a] f' :: (Monad m, _) => [m a] -> m [a] f = f' f' [] = return [] f' (x:xx) = f xx |] }}} {{{ [1 of 1] Compiling Minimal ( /Users/pepe/Dropbox/code/debug- hoed/test/minimal.hs, interpreted ) /Users/pepe/Dropbox/code/debug-hoed/test/minimal.hs:5:1: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘()’ • In the type signature: f :: (Monad m_a7NN, _) => [m_a7NN a_a7NO] -> m_a7NN [a_a7NO] | 5 | id [d| | ^^^^^^... /Users/pepe/Dropbox/code/debug-hoed/test/minimal.hs:5:1: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘()’ • In the type signature: f' :: (Monad m_a7NL, _) => [m_a7NL a_a7NM] -> m_a7NL [a_a7NM] | 5 | id [d| | ^^^^^^... Ok, one module loaded. :browse f :: (Monad m, Monad m) => [m a] -> m [a] f' :: (Monad m, Monad m) => [m a] -> m [a] }}} Notice the duplicate Monad m constraint. Things get even more weird if the type signatures are declared together: {{{#!hs id [d| f, f' :: (Monad m, _) => [m a] -> m [a] f = f' f' [] = return [] f' (x:xx) = f xx |] }}} {{{ [1 of 1] Compiling Minimal ( /Users/pepe/Dropbox/code/debug- hoed/test/minimal.hs, interpreted ) /Users/pepe/Dropbox/code/debug-hoed/test/minimal.hs:5:1: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘()’ • In the type signature: f :: (Monad m_a88E, _) => [m_a88E a_a88F] -> m_a88E [a_a88F] | 5 | id [d| | ^^^^^^... /Users/pepe/Dropbox/code/debug-hoed/test/minimal.hs:5:1: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘()’ • In the type signature: f' :: (Monad m_a88E, _) => [m_a88E a_a88F] -> m_a88E [a_a88F] | 5 | id [d| | ^^^^^^... Ok, one module loaded. :browse f :: (Monad ghc-prim-0.5.1.1:GHC.Types.Any, Monad m) => [ghc-prim-0.5.1.1:GHC.Types.Any ghc-prim-0.5.1.1:GHC.Types.Any] -> ghc-prim-0.5.1.1:GHC.Types.Any [ghc-prim-0.5.1.1:GHC.Types.Any] f' :: (Monad ghc-prim-0.5.1.1:GHC.Types.Any, Monad m) => [m a] -> m [a] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14658: 'Fix two more bugs in partial signatures' broke T10846
by GHC 03 Apr '18

03 Apr '18

#14658: 'Fix two more bugs in partial signatures' broke T10846 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- {{{ =====> T10846(normal) 1 of 1 [0, 0, 0] cd "./typecheck/should_run/T10846.run" && "/home/niteria/ghc-allocate- tyids/inplace/test spaces/ghc-stage2" -o T10846 T10846.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output cd "./typecheck/should_run/T10846.run" && ./T10846 Actual stdout output differs from expected: diff -uw "./typecheck/should_run/T10846.run/T10846.stdout.normalised" "./typecheck/should_run/T10846.run/T10846.run.stdout.normalised" --- ./typecheck/should_run/T10846.run/T10846.stdout.normalised 2018-01-10 13:39:29.720468420 +0000 +++ ./typecheck/should_run/T10846.run/T10846.run.stdout.normalised 2018-01-10 13:39:29.720468420 +0000 @@ -1,3 +1,3 @@ [18] -[19] -[20] +[] +[] *** unexpected failure for T10846(normal) }}} Harbormaster results: https://phabricator.haskell.org/harbormaster/build/39597/ Reverting fixed it for me locally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14897: QuantifiedConstraints: Can't print type of quantified constraint
by GHC 02 Apr '18

02 Apr '18

#14897: QuantifiedConstraints: Can't print type of quantified constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language QuantifiedConstraints, FlexibleInstances, UndecidableInstances, MonoLocalBinds #-} class (forall xx. Functor (f xx)) => Functor' f instance (forall xx. Functor (f xx)) => Functor' f fmap' :: Functor' f => (b -> b') -> (f a b -> f a b') fmap' = fmap }}} load in ghci and check the type of `fmap'` {{{ $ ... -ignore-dot-ghci Bug2.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Ok, one module loaded. *Main> :t fmap' <interactive>:1:1: error: No instance for (Functor (f xx)) arising from a use of ‘fmap'’ *Main> }}} Simpler example {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XRankNTypes -XQuantifiedConstraints Prelude> let a :: (forall xx. Monoid (f xx)) => f a; a = mempty Prelude> :t a <interactive>:1:1: error: No instance for (Monoid (f xx)) arising from a use of ‘a’ Prelude> }}} I expected the same output as `:t +v` {{{ Prelude> :t +v a a :: (forall xx. Monoid (f xx)) => f a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14119: Refactor type patterns
by GHC 02 Apr '18

02 Apr '18

#14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 12564, 14038 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type patterns are used in instance heads: class instances, type instances, and data/newtype instances. These type patterns differ from ordinary types in several ways: * They must never mention a `forall`. * They must never mention a context. (The context in a class instance head is a different part of the instance construct.) * They must never mention a type family. Types that appear as arguments on the LHS of a RULE should also be type patterns. Type patterns are used in GHC differently than types as well: we should match only against patterns, never ordinary types. I thus propose that a new datatype within GHC to store type patterns. I'll call it `TyPat` here, but perhaps a longer name is better. The matcher (in the `Unify` module) would then take a `TyPat` parameter, making clear which type is the template and which is the concrete instantiation. We could have a new algorithm to typecheck/desugar source syntax into patterns. This new algorithm could accommodate issues like those mentioned in comment:6:ticket:14038. It could also avoid ever putting a type family in a kind parameter, which would fix #12564. Separating out checking type patterns from proper types could also improve GADT pattern matching in types, which is currently more like "wobbly types" than OutsideIn. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking
by GHC 02 Apr '18

02 Apr '18

#14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | 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: -------------------------------------+------------------------------------- ghc-stage2 panic! due to assertion failure when compiling the following code with `ghc-stage2 Bug.hs` {{{#!hs module Bug where x :: IO () x = _ print "abc" }}} Callstack: {{{ λ inplace\bin\ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180225 for x86_64-unknown-mingw32): ASSERT failed! t_a4ec[tau:2] 2 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\utils\Outputable.hs:1206:5 in ghc:Outputable assertPprPanic, called at compiler\\typecheck\\TcType.hs:1187:83 in ghc:TcType CallStack (from -prof): TcInteract.solve_loop (compiler\typecheck\TcInteract.hs:(247,9)-(254,44)) TcInteract.solveSimples (compiler\typecheck\TcInteract.hs:(241,5)-(243,21)) TcRnDriver.simplifyTop (compiler\typecheck\TcRnDriver.hs:408:25-39) TcRnDriver.tcRnSrcDecls (compiler\typecheck\TcRnDriver.hs:254:25-65) }}} The failed assertion is `checkTcLevelInvariant ctxt_tclvl tv_tclvl` in `isTouchableMetaTyVar`: {{{#!hs isTouchableMetaTyVar :: TcLevel -> TcTyVar -> Bool isTouchableMetaTyVar ctxt_tclvl tv | isTyVar tv -- See Note [Coercion variables in free variable lists] = ASSERT2( tcIsTcTyVar tv, ppr tv ) case tcTyVarDetails tv of MetaTv { mtv_tclvl = tv_tclvl } -> ASSERT2( checkTcLevelInvariant ctxt_tclvl tv_tclvl, ppr tv $$ ppr tv_tclvl $$ ppr ctxt_tclvl ) tv_tclvl `sameDepthAs` ctxt_tclvl _ -> False | otherwise = False }}} Notice that the ghc-stage1 compiler doesn't panic and report the type hole correctly. This seems a regression and I have checked that ghc-8.2.2 also works well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6