May 2015 - ghc-tickets

[GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors
by GHC 07 Jul '15

07 Jul '15

#10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, there seems to be no way to suppress warnings generated by `-fdefer-type-errors` (even `-w` doesn't work). It would be nice to be able to silence them, preferably via a new flag `-fno-warn-deferred-type- errors`. The motivation for this comes from using `-fdefer-type-errors` to write tests that certain definitions do not typecheck (which is very useful, and is a cheaper alternative to writing code to invoke GHC on a source file and analyse its output). In this situation, it is annoying to see a large number of warnings when compiling the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10205: On Windows ghc-pkg always reports cache out of date
by GHC 07 Jul '15

07 Jul '15

#10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- When I ran {{{ghc-pkg list}}} on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below. Original error: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg check WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Checking timestamps: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:18:29.5247984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:18:29.5277984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Recaching as instructed: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --user [snip...] modifying: Just "C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d" flag db stack: ["C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"] writing cache C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --global [snip...] modifying: Just "C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d" flag db stack: ["C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"] writing cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache }}} Looking at timestamps after recaching: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:21:50.3341984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:21:50.3371984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. C:\Users\hgolden\AppData\Roaming> }}} Timestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)
by GHC 07 Jul '15

07 Jul '15

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling the test case with: ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs Now, trying with some inputs and -N2 $ ./ghc-bug 7 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 6 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 5 +RTS -N2 => 3125 $ ./ghc-bug 5 +RTS -N2 ghc-bug: <<loop>> Reducing the number of capabilities to 1, it works for those inputs $ ./ghc-bug 7 +RTS -N1 As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [http://lpaste.net/132564/ original testcase] felt a bit more deterministic, but I think the testcase in the ticket is good enough) I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian Similar bug: [10218] (-fno-cse and -flate-dmd-anal didn't help with this) {{{#!hs import Control.Applicative import Control.Monad import Control.Parallel.Strategies import System.Environment newtype ParList a = ParList { unParList :: [a] } nil :: ParList a nil = ParList [] cons :: a -> ParList a -> ParList a cons x (ParList xs) = ParList (x:xs) instance Functor ParList where fmap = liftM instance Applicative ParList where pure = return (<*>) = ap instance Monad ParList where return = ParList . return {- v code that doesn't work -} (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs >>= unParList . f)) --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs)) {- ^ code that works -} type Pair = (Int, [Int]) loop' :: Pair -> ParList Pair loop' (size,qns) = go 1 where go n | n > size = nil | otherwise = cons (size, n:qns) (go (n+1)) worker :: Int -> Pair -> [Pair] worker n = unParList . go n where go 1 = loop' go n = loop' >=> go (n-1) main :: IO () main = do [n] <- (read <$>) <$> getArgs print $ length (worker n (n,[])) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #9839: RTS options parser silently accepts invalid flags
by GHC 05 Jul '15

05 Jul '15

#9839: RTS options parser silently accepts invalid flags -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: #4243 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- RTS options that do not take arguments (such as `-T`) silently ignore anything that comes afterwards. For example, `+RTS -T,-s` or `+RTS -T-s` turns on collection of GC statistics (`-T`) but does not print out a summary (`-s`). Instead, this should produce an error message. Otherwise, users may mistakenly think that options have been applied. (This has just bitten us in a production system.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8206: Add support for Portable Native Client
by GHC 05 Jul '15

05 Jul '15

#8206: Add support for Portable Native Client -------------------------------------------------+------------------------- Reporter: guest | Owner: Alex Type: feature request | Sayers Priority: normal | Status: new Component: Compiler | Milestone: Keywords: NaCl PNaCl Portable Native | Version: Client pexe | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- == Motivation == [http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable- native-client Portable Native Client] (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near- native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator. == Portable Native Client == The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The [https://developers.google.com /native-client/pepperc/ Pepper API], a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page. PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client. == The Easily-Fixed == The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides `pnacl-finalize`, which translates LLVM bitcode into pexe bitcode. PNaCl [http://www.chromium.org/nativeclient/pnacl/bitcode- abi##callingconventions only allows] the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2. It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit. == The Not-So-Easily-Fixed == The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to `mmap`, which the GHC runtime uses to request memory allocation. It seems, therefore, that significant chunks of the RTS will have to be ported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8353: Easy way to defer type errors
by GHC 04 Jul '15

04 Jul '15

#8353: Easy way to defer type errors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A number of comments I've heard recently have focused on the joy of `-fdefer-type-errors`, especially for newcomers to Haskell. However, in GHCi, one has to 1. be aware that `-fdefer-type-errors` exists 2. know the `:set ...` syntax to turn it on, and then 3. is stuck with this setting on until they turn it off Instead, I propose new `:load!` and `:reload!` commands (abbreviated to `:l!` and `:r!`) which turn on `-fdefer-type-errors` just for that one command. When a load or reload fails, the error message could suggest these alternate forms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9723: Give Tab warning only once per file
by GHC 04 Jul '15

04 Jul '15

#9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when compiling a tabbed file, GHC spits out a huge number of warnings: {{{ Main.hs:1:1: Warning: Tab character [..] Main.hs:89:1: Warning: Tab character Main.hs:90:1: Warning: Tab character Main.hs:91:1: Warning: Tab character Main.hs:92:1: Warning: Tab character Main.hs:99:4: Warning: Tab character Main.hs:100:4: Warning: Tab character Main.hs:101:4: Warning: Tab character }}} This is annoying and not very nice to our users. I suggest to replace it by {{{ This file contains tabs (e.g. line n column m); please use spaces instead }}} or (to be nice to tools that parse this output) {{{ Main.hs:1:1: Tab found here, and in n further locations. Please use spaces instead. }}} (This is clearly a low priority request, but also possibly some low- hanging fruit for new contributors.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8881: No way to unsubscribe a bug
by GHC 04 Jul '15

04 Jul '15

#8881: No way to unsubscribe a bug ------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current trac settings are so that when I comment on a bug, I am automatically subscribed to it. This is good, but there should be way to unsubscribe from a bug as well. Also, and I’m not sure if this is the same thing or not, if I put myself in the “Observer” list (possibly wrong translation), I cannot undo that. Generally, we might give our users more permissions, e.g. to edit ticket descriptions (and not just the summary). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252
by GHC 04 Jul '15

04 Jul '15

#10402: powerpc: unhandled ELF relocation(RelA) type 252 -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: powerpc | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Building some Debian packages on powerpc with GHC 7.8.4 fails as shown in this [https://buildd.debian.org/status/fetch.php?pkg=haskell-wai-app- static&arch=powerpc&ver=3.0.1-3&stamp=1431236338 build log], e.g.: {{{ ghc: /usr/lib/haskell-packages/ghc/lib/powerpc-linux-ghc-7.8.4/unix- time-0.3.5/libHSunix-time-0.3.5.a: unhandled ELF relocation(RelA) type 252 }}} I'm no PPC ABI expert, but I think the attached patch against master (which applies equally to 7.8.4) is reasonably plausible, and it at least allows wai-app-static to build cleanly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with
by GHC 03 Jul '15

03 Jul '15

#8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- make -j3 fails with Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestar… for details. Stop. make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13