June 2015 - ghc-tickets

[GHC] #10502: Bad interaction of sandboxes and coverage
by GHC 09 Jun '15

09 Jun '15

#10502: Bad interaction of sandboxes and coverage -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.10.1 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It seems that when using sandboxes with project and coverage (`--enable- coverage`) cabal fails to generate and find .mix files for dependencies. Steps to reproduce: 1. create shared sandbox (not sure that shared sandbox plays it's role here): {{{cabal sandbox init --sandbox=../.shared}}} 2. install all dependencies with enable-coverage {{{cabal install --dependencies-only --enable-coverage --enable-tests}}} 3. install library {{{cabal install --enable-coverage --run-tests}}} Expected results: 1. Library will be built, coverage output will be generated. Actual results: hpc fails to find .mix files: {{{ hpc: can not find netwo_Bdsn6Y1VKLa3MCczwSV70J/Network.Socket.ByteString.MsgHdr in ["./.hpc" ,"./dist/dist-sandbox-f7da581b/hpc/vanilla/mix/network-transport- tcp-0.4.1" ,"./dist/dist-sandbox-f7da581b/hpc/vanilla/mix/TestTCP"] }}} Tested on ghc-7.10.1 in clear official docker container on network- transport-tcp package. Side node: during tests on bigger project I have seen similar failures even on step 2 (e.g. network package fails with similar error message), but I was not able to reproduce it in minimal example. Possibly related report: #10259 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10443: Regression in forall typechecking
by GHC 09 Jun '15

09 Jun '15

#10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following bug showed up when trying to install ghc-mod against the current ghc-7.10 branch Ths code below, from https://github.com/DanielG/ghc- mod/blob/b52c0a5d767282369f2748c5ec070b802ed8e23c/Language/Haskell/GhcMod/Monad/Types.hs#L346 {{{#!hs instance (MonadBaseControl IO m) => MonadBaseControl IO (GhcModT m) where type StM (GhcModT m) a = StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m) ) ) ) a liftBaseWith f = GhcModT . liftBaseWith $ \runInBase -> f $ runInBase . unGhcModT restoreM = GhcModT . restoreM {-# INLINE liftBaseWith #-} {-# INLINE restoreM #-} }}} Which compiles fine with GHC 7.10.1 now has the error {{{ Language/Haskell/GhcMod/Monad/Types.hs:346:13: Couldn't match expected type ‘StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a1 -> IO (StM m (Either GhcModError (a1, GhcModState), GhcModLog))’ with actual type ‘forall a2. StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a2 -> IO (StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m)))) a2)’ Relevant bindings include runInBase :: forall a. StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a -> IO (StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m)))) a) (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:48) f :: RunInBase (GhcModT m) IO -> IO a (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:18) liftBaseWith :: (RunInBase (GhcModT m) IO -> IO a) -> GhcModT m a (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:5) In the first argument of ‘(.)’, namely ‘runInBase’ In the second argument of ‘($)’, namely ‘runInBase . unGhcModT’ }}} A laborious git bisect tracked it down to {{{ 681d82c0d44f06f0b958b75778c30b0910df982b is the first bad commit commit 681d82c0d44f06f0b958b75778c30b0910df982b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Apr 7 14:45:04 2015 +0100 Look inside synonyms for foralls when unifying This fixes Trac #10194 (cherry picked from commit 553c5182156c5e4c15e3bd1c17c6d83a95a6c408) :040000 040000 1f0e62661ed1c48a9cbfab72ca3e38bb9e501412 ef6786fdb952d3446121b27b56f6103533d52356 M compiler :040000 040000 d607f1bff94578b0677df9cba01371dad6b26a32 ac715cec4fd8d43a53ecee132eae2b4c0c65e31a M testsuite }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable!
by GHC 09 Jun '15

09 Jun '15

#10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: Build | Operating System: Unknown/Multiple System | Type of failure: Building GHC Keywords: | failed Architecture: x86 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I didn't check ghc-7.10.1-testsuite.tar.bz2 but at least ghc-7.10.1-testsuite.tar.xz contains testsuite/mk/ghc-config which is a 64bit Linux executable. This causes the testsuite to fail on non-x86_64 arches eg i686 Linux, etc since it can't be executed. A workaround is to rm testsuite/mk/ghc-config. It would be good to avoid this for 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 09 Jun '15

09 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (For a build that's about 1 minute, FWIW) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 09 Jun '15

09 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Here's a smaller version (that actually completes in a reasonable amount of time), along with a profile. Something is definitely quadratic or something around `CorePrep`/`TidyCore`; when run with `-v3`, I estimate `CorePrep` alone takes about 20 seconds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 09 Jun '15

09 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I've updated the test case. By default, even on my monster build machine, it looks like the compilation of this test is literally never going to finish, so it needs to be toned down to look at it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10441: msys native python testsuite support doesn't work in some situations
by GHC 09 Jun '15

09 Jun '15

#10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is: {{{ cd ./typecheck/should_compile && "C:/msys64/home/ezy.exe" -c tc055.hs -fforce-recomp -dcore-lint -dcmm-lib -rtsopts -fno-warn-tabs -fno-ghci- history -fno-warnrr 2>&1 '..\timeout\install-inplace\bin\timeout.exe" "300" "cexternal command, operable program or batch file. Compile failed (status 256) errors were: }}} I have diagnosed the problem to the fact that we are passing a complex command string to cmd with adequately quoting it. In particular, when I inspect the command line that Python is attempting to invoke, it looks something like this: {{{ cmd \c 'timeout.exe 300 "cd . && "inplace/ghc-stage2" -c blah blah"' }}} Notice, in particular, that the quoted GHC executable was not inside the timeout invocation is not double-quoted, so cmd does NOT parse the command the way you want it to. Curiously enough, when I remove this fix (introduced by commit `101c62e26286353dd3fac1ef54323529b64c9902`), the msys Python runner works fine. So I don't even know what this commit was intended to fix; it seems to have done more harm than good Here are some details about my configuration: {{{ ezyang@cutlass MSYS ~/ghc-validate/testsuite $ python2 --version Python 2.7.9 ezyang@cutlass MSYS ~/ghc-validate/testsuite $ bash --version GNU bash, version 4.3.33(3)-release (x86_64-pc-msys) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9626: Test command lines munged on Windows when running on msys Python
by GHC 09 Jun '15

09 Jun '15

#9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On Windows, the test runner works fine if run under Windows-native Python, but fails with the msys Python because of the heuristic transformations that msys applies to all binary invocations of non-msys binaries (such as timeout.exe) by msys binaries (such as python). This is relatively easy to sidestep by going through /usr/bin/cmd in msys which sidesteps the argument munging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10501: Exception in :cmd command can terminate GHCi
by GHC 09 Jun '15

09 Jun '15

#10501: Exception in :cmd command can terminate GHCi ----------------------------------+------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------+------------------------------- {{{ watashi % ghci -ignore-dot-ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :cmd return $ head [] ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for i386-unknown-linux): Prelude.head: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10488: Inconsistent reduction of type family
by GHC 08 Jun '15

08 Jun '15

#10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, GADTs, PolyKinds, DataKinds, ScopedTypeVariables, TypeOperators, UndecidableInstances #-} module SingBug where import Data.Singletons.TH $(promote [d| data Nat = Zero | Succ Nat deriving (Eq, Ord) |]) foo :: Proxy (Zero :< Succ Zero) foo = (Proxy :: Proxy True) }}} It fails to compile, with this: {{{ SingBug.hs:14:8: Couldn't match type ‘'False’ with ‘'True’ Expected type: Proxy ('Zero :< 'Succ 'Zero) Actual type: Proxy 'True In the expression: (Proxy :: Proxy True) In an equation for ‘foo’: foo = (Proxy :: Proxy True) }}} However, if I remove the last two lines, it compiles fine. Witness this bizarre interaction: {{{ Prelude> :load "SingBug.hs" [1 of 1] Compiling SingBug ( SingBug.hs, interpreted ) Ok, modules loaded: SingBug. *SingBug> :kind! Zero :< Succ Zero Zero :< Succ Zero :: Bool = TrueSym0 *SingBug> :i TrueSym0 type TrueSym0 = 'True -- Defined in ‘singletons-1.2:Data.Singletons.Prelude.Instances’ *SingBug> :kind! (Proxy (Zero :< Succ Zero)) (Proxy (Zero :< Succ Zero)) :: * = Proxy TrueSym0 *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy ('Zero :< 'Succ 'Zero) *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True <interactive>:1:2: Couldn't match type ‘'False’ with ‘'True’ Expected type: Proxy 'True Actual type: Proxy ('Zero :< 'Succ 'Zero) In the expression: (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False :: Proxy 'False }}} It seems GHC can't decide if 0 is less than 1! When I ask it to use `:kind!`, it does the right thing. But if it's reducing a type during type-checking, it does very much the '''wrong''' thing. This is a regression compared to 7.8. I've been unable to minimize the test case or remove the `singletons` dependency, sadly. When I try to mimic the behavior of singletons without TH, it all works as expected. But I've found the problem. The apartness check for closed type families is very subtly broken, and I believe you can break the type system exploiting this bug. I can't quite tickle it directly though. Fix on the way in the next day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5