May 2015 - ghc-tickets

[GHC] #8172: Expose CWD and import search paths in GHCi via new `:show paths` command
by GHC 11 Jun '15

11 Jun '15

#8172: Expose CWD and import search paths in GHCi via new `:show paths` command -------------------------------------------+------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- - Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path. - Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` options are currently in effect. The attached patch extends `:show` with a `:show paths` subcommand, printing the CWD and the current value of `importPaths`: {{{ Ok, modules loaded: Main, InteractiveUI, Paths_ghci_ng, GhciMonad, GhciTags. λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: dist/build/ghci-ng/ghci-ng-tmp ghc dist/build/autogen λ> :set -i λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: none > :cd /tmp Warning: changing directory causes all loaded modules to be unloaded, because the search path has changed. > :show paths current working directory: /tmp module import search paths: none }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10127: There is no ghc-7.8.4 for 32 bit Windows
by GHC 10 Jun '15

10 Jun '15

#10127: There is no ghc-7.8.4 for 32 bit Windows -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Windows-32 is no longer listed as a supported platform, nor is there an installer. Is this intentional? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9945: export list for System.Posix.Internals breaking the build on Windows
by GHC 10 Jun '15

10 Jun '15

#9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: #9852 Differential Revisions: | -------------------------------------+------------------------------------- The export list in System.Posix.Internals includes some names that, thanks to CPP, aren't defined when building on Windows. It was compiling fine a few days ago, so I think [Phab:D551] was the breaking change. I attach the `make` output from the failing step. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9663: Windows build process should give better message if you forgot to clone tarballs
by GHC 09 Jun '15

09 Jun '15

#9663: Windows build process should give better message if you forgot to clone tarballs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you forget to clone ghc-tarballs into the directory when building on Windows, configure will report that it can't find a working C compiler. It would be nice if there was a better error message here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9101: Build 7.8.2 from sources on Windows/msys2
by GHC 09 Jun '15

09 Jun '15

#9101: Build 7.8.2 from sources on Windows/msys2 ------------------------------------+--------------------------------- Reporter: cchantep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hi, Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra), even system/env provide such tools (e.g. using pacman package manager in msys2): https://ghc.haskell.org/trac/ghc/browser/ghc/configure.ac#L274 . It leads to issues as tools in inplace are quite old. Particularly it can be critical about linking: GHC will be working with old ld, but you can have built/linked libraries using the more recent ld. Then, what's built using system tool can't be used throught GHC (ld version conflict). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10259: HPC code coverage fails
by GHC 09 Jun '15

09 Jun '15

#10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: | Owner: LukeHoersten | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: MacOS X Keywords: hpc | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- in a completely clean sandbox environment: cabal install --dependencies-only --enable-tests --enable-coverage --enable-benchmarks cabal build test --dependencies-only --enable-tests --enable-coverage --enable-benchmarks cabal test project --test-options=--html=dist/tasty/index.html Command: cabal test project --test-options=--html=dist/tasty/index.html Exit code: 1 Stderr: hpc: can not find text_IINWRW1LxFGIctooOLjJAI/Data.Text.Unsafe in ["./.hpc","./dist/hpc/vanilla/mix/project-0.1.0.0","./dist/hpc/vanilla/mix /project-test"] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cabal --version cabal-install version 1.22.2.0 using version 1.22.2.0 of the Cabal library $ clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix OS X version 10.10.3 Installed from home-brew and Haskell for Mac OS X both have the same problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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

[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