July 2015 - ghc-tickets

[GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python
by GHC 12 Aug '15

12 Aug '15

#9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------------+---------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+---------------------------- The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown- mingw32.tar.xz includes the following under `mingw/bin`: * gfortran * gcj * python27.dll * The whole Python 2.7 standard library (`mingw/bin/lib`) These files have probably been included by mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by GHC 12 Aug '15

12 Aug '15

#9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10339: PatternSynonyms confuse exhaustiveness check
by GHC 10 Aug '15

10 Aug '15

#10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I just noticed some odd behaviour when (ab)using pattern synonyms in the following code (whose style I don't really endorse): {{{#!hs {-# LANGUAGE PatternSynonyms, LambdaCase #-} module PatSyn1 where import System.Directory (doesFileExist) pattern Found = True pattern NotFound = False readConfigFile :: FilePath -> IO () readConfigFile filePath = doesFileExist filePath >>= \case Found -> putStrLn =<< readFile filePath NotFound -> putStrLn "File does not exist." pattern Void = () foo :: () -> () foo Void = () }}} Results in {{{ /home/hvr/Haskell/PatSyn1.hs:(11,54)-(13,47): Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ /home/hvr/Haskell/PatSyn1.hs:19:1-13: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | 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: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10540: Showing type synonym isn't exported by Hoopl
by GHC 08 Aug '15

08 Aug '15

#10540: Showing type synonym isn't exported by Hoopl -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/hoopl | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hoopl exports {{{#!hs showGraph :: Showing n -> Graph n e x -> String }}} But it doesn't export `Showing`. This doesn't make sense, as it's a user- supplied function. So to know what I should pass to `showGraph` I can only look at the source. `:i Showing` doesn't work. Below is a patch to export the innocent type synonym: {{{#!patch diff --git a/src/Compiler/Hoopl/Show.hs b/src/Compiler/Hoopl/Show.hs index 8a8b35f..66172b0 100644 --- a/src/Compiler/Hoopl/Show.hs +++ b/src/Compiler/Hoopl/Show.hs @@ -4,7 +4,7 @@ #endif module Compiler.Hoopl.Show - ( showGraph, showFactBase + ( showGraph, showFactBase, Showing ) where }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10067: The Read Integer instance is too slow
by GHC 07 Aug '15

07 Aug '15

#10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following: {{{#!hs read (take 1000000 $ cycle "1234567890") :: Integer }}} Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10340: Type inference regression with Any
by GHC 07 Aug '15

07 Aug '15

#10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 module typechecks with GHC 7.8.3, but GHC 7.10.1 gives an error: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module Foo where import GHC.Exts (Any) class MonadState s m where get :: m s newtype State s a = State (s -> (s, a)) instance MonadState s (State s) where get = State $ \s -> (s, s) foo :: State Any Any foo = get }}} {{{ [1 of 1] Compiling Foo ( any.hs, any.o ) any.hs:15:7: No instance for (MonadState Any (State Any)) arising from a use of ‘get’ In the expression: get In an equation for ‘foo’: foo = get }}} If I replace the uses of `Any` with `Int`, the problem goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10609: Make up instances
by GHC 07 Aug '15

07 Aug '15

#10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following instances are missing as of now. * Foldable ZipList * Traversable ZipList * Functor Complex * Foldable Complex * Traversable Complex * Applicative Complex * Monad Complex * Monoid a => Monoid (Identity a) Original discussion: https://mail.haskell.org/pipermail/libraries/2015-June/025886.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5