November 2016 - ghc-tickets

[GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations
by GHC 03 Dec '16

03 Dec '16

#12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2-rc1 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: -------------------------------------+------------------------------------- `quickcheck-combinators-0.0.1` fails to build with GHC 8.0.2-rc1 (but does build with GHC 8.0.1) due to this issue. Here is a simplified example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} Is this expected? If so, we should make a note of this in the 8.0.2 release notes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't
by GHC 02 Dec '16

02 Dec '16

#12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: MADV_FREE | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In osDecommitMemory there is a [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c1… #define] for MADV_FREE. The presence of MADV_FREE is detected by the [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c1… configure] script, however merely testing for the presence of this symbol does not prove that MADV_FREE is supported by the kernel (which was [https://kernelnewbies.org/Linux_4.5#head- 42578a3e087d5bcc2940954a38ce794fe2cd642c introduced in 4.5]). On newer versions of GCC (e.g. 6.1.1 on Alpine Edge), [https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=981569c74cbb6bafa2dd… MADV_FREE is included in the compiler's header files], thus leading to a false positive. The impact of this bug is that when GHC is compiled with a more recent version of GCC, "unable to decommit memory: Invalid argument" errors will abound. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12735: Evaluate the feasibility of using lld for linking
by GHC 02 Dec '16

02 Dec '16

#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [DynamicLinkingDebate]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker] Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
by GHC 02 Dec '16

02 Dec '16

#11744: Latest Xcode update violates POSIX compliance of `nm -P` ----------------------------------------+--------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>, <size>}}} In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11724: Must check for representation polymorphism in datatype declarations
by GHC 02 Dec '16

02 Dec '16

#11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- {{{#!hs data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a }}} panics. It should error instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12668: Program that fails Core Lint terribly
by GHC 02 Dec '16

02 Dec '16

#12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- While looking for a testcase for another unrelated compiler bug (see Phab:D2577) I had the pleasure of encountering this specimen, {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data Some r = Some (TYPE r -> TYPE r) doSomething :: forall (r :: RuntimeRep). forall (a :: TYPE r). () => Int -> (a -> Int) -> a -> a doSomething n f = case n of 1 -> error "hello" 3 -> error "hello" }}} GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 seems to let this program typecheck, but if you enable Core Lint it soon becomes clear that not all is well. Here's a sampling of the carnage, {{{ $ ghc hi.hs -fforce-recomp -dcore-lint -O0 [1 of 1] Compiling Hi ( hi.hs, hi.o ) *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: In the type ‘a_a2ON -> Int’ Ill-kinded argument in type or kind ‘a_a2ON -> Int’ type or kind ‘a_a2ON -> Int’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the expression: patError @ 'PtrRepLifted @ (a_a2ON -> a_a2ON) "hi.hs:(12,5)-(14,24)|case"# Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8848: Warning: Rule too complicated to desugar
by GHC 02 Dec '16

02 Dec '16

#8848: Warning: Rule too complicated to desugar ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've a very very modest application of Specialize to fixed sized lists in some of my code which seems to trip up the specialization machinery. Is there any flags I can pass GHC to make sure it doesn't give up on these specialize calls? is the only work around to write my own monomorphic versions and add some hand written rewrite rules?! {{{ rc/Numerical/Types/Shape.hs:225:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XB :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XB = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in map2 @ a @ b @ c @ ('S ('S 'Z)) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) (Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XB) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XB Numerical.Types.Shape.$fApplicativeShape0)) src/Numerical/Types/Shape.hs:226:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XG :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XG = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in let { $dFunctor_a3XF :: Functor (Shape ('S ('S 'Z))) [LclId, Str=DmdType] $dFunctor_a3XF = Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XG } in map2 @ a @ b @ c @ ('S ('S ('S 'Z))) (Numerical.Types.Shape.$fApplicativeShape @ ('S ('S 'Z)) (Numerical.Types.Shape.$fFunctorShape @ ('S ('S 'Z)) $dFunctor_a3XF) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) $dFunctor_a3XF (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XG Numerical.Types.Shape.$fApplicativeShape0))) }}} the associated code (smashed into a single module ) is {{{ {-# LANGUAGE DataKinds, GADTs, TypeFamilies, ScopedTypeVariables #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Data import Data.Typeable() import Data.Type.Equality import qualified Data.Monoid as M import qualified Data.Functor as Fun import qualified Data.Foldable as F import qualified Control.Applicative as A import Prelude hiding (foldl,foldr,init,scanl,scanr,scanl1,scanr1) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable 'Z deriving instance Typeable 'S #endif type family n1 + n2 where Z + n2 = n2 (S n1') + n2 = S (n1' + n2) -- singleton for Nat data SNat :: Nat -> * where SZero :: SNat Z SSucc :: SNat n -> SNat (S n) --gcoerce :: (a :~: b) -> ((a ~ b) => r) -> r --gcoerce Refl x = x --gcoerce = gcastWith -- inductive proof of right-identity of + plus_id_r :: SNat n -> ((n + Z) :~: n) plus_id_r SZero = Refl plus_id_r (SSucc n) = gcastWith (plus_id_r n) Refl -- inductive proof of simplification on the rhs of + plus_succ_r :: SNat n1 -> Proxy n2 -> ((n1 + (S n2)) :~: (S (n1 + n2))) plus_succ_r SZero _ = Refl plus_succ_r (SSucc n1) proxy_n2 = gcastWith (plus_succ_r n1 proxy_n2) Refl type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 {- Need to sort out packed+unboxed vs generic approaches see ShapeAlternatives/ for -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} newtype At a = At a deriving (Eq, Ord, Read, Show, Typeable, Functor) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Show) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable Shape #endif instance Eq (Shape Z a) where (==) _ _ = True instance (Eq a,Eq (Shape s a))=> Eq (Shape (S s) a ) where (==) (a:* as) (b:* bs) = (a == b) && (as == bs ) instance Show (Shape Z a) where show _ = "Nil" instance (Show a, Show (Shape s a))=> Show (Shape (S s) a) where show (a:* as) = show a ++ " :* " ++ show as -- at some point also try data model that -- has layout be dynamicly reified, but for now -- keep it phantom typed for sanity / forcing static dispatch. -- NB: may need to make it more general at some future point --data Strided r a lay = Strided { getStrides :: Shape r a } {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) instance Fun.Functor (Shape Z) where fmap = \ _ Nil -> Nil --{-# INLINE fmap #-} instance (Fun.Functor (Shape r)) => Fun.Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* Fun.fmap f rest --{-# INLINE fmap #-} instance A.Applicative (Shape Z) where pure = \ _ -> Nil --{-# INLINE pure #-} (<*>) = \ _ _ -> Nil --{-# INLINE (<*>) #-} instance A.Applicative (Shape r)=> A.Applicative (Shape (S r)) where pure = \ a -> a :* (A.pure a) --{-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (A.<*>)) fs as --{-# INLINE (<*>) #-} instance F.Foldable (Shape Z) where foldMap = \ _ _ -> M.mempty --{-# fold #-} foldl = \ _ init _ -> init foldr = \ _ init _ -> init foldr' = \_ !init _ -> init foldl' = \_ !init _ -> init instance (F.Foldable (Shape r)) => F.Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a M.<> F.foldMap f as foldl' = \f !init (a :* as) -> let next = f init a in next `seq` F.foldl f next as foldr' = \f !init (a :* as ) -> f a $! F.foldr f init as foldl = \f init (a :* as) -> let next = f init a in F.foldl f next as foldr = \f init (a :* as ) -> f a $ F.foldr f init as -- map2 :: (A.Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> A.pure f A.<*> l A.<*> r {-# SPECIALIZE map2 :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S Z) a )-> Shape (S Z) b -> Shape (S Z) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S Z)) a )-> Shape (S (S Z)) b -> Shape (S (S Z)) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S(S Z))) a )-> Shape (S (S (S Z))) b -> Shape (S (S(S Z))) c #-} -- {-# INLINABLE map2 #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12901: Levity polymorphic expressions mustn't be floated out
by GHC 02 Dec '16

02 Dec '16

#12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been trying to add the following code into GHC: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} pattern AppOp1 :: PrimOp -> Arg CoreBndr -> CoreExpr pattern OpVal :: PrimOp -> Arg CoreBndr pattern AppOp1 op x = App (OpVal op) x pattern OpVal op <- Var (isPrimOpId_maybe -> Just op) where OpVal op = Var (mkPrimOpId op) }}} It triggers the following CoreLint error: {{{ <no location info>: warning: [RHS of lvl_spfb :: r] RuntimeRep-polymorphic binder: lvl_spfb :: (r :: TYPE rep) }}} Indeed: {{{#!hs $mAppOp1 :: forall (r :: TYPE rep). CoreExpr -> (PrimOp -> Arg CoreBndr -> r) -> (Void# -> r) -> r [LclIdX, Arity=3] $mAppOp1 = \ (@ (rep_agRe :: RuntimeRep)) (@ (r_agRf :: TYPE rep)) (scrut_agRh :: CoreExpr) (cont_agRi :: PrimOp -> Arg CoreBndr -> r) (fail_agRj :: Void# -> r) -> let { fail_spbW :: Void# -> r [LclId, Arity=1] fail_spbW = \ _ [Occ=Dead, OS=OneShot] -> fail_agRj void# } in let { lvl_spfb :: r [LclId] lvl_spfb = fail_spbW void# } in case scrut_agRh of { __DEFAULT -> fail_spbW void#; App ds_dj2u x_afoV -> $mOpVal @ rep @ r ds_dj2u (\ (op_afoU :: PrimOp) -> cont_agRi op_afoU x_afoV) (\ _ [Occ=Dead] -> lvl_spfb) }}} According to the levity polymorphism paper `lvl_spfb` shouldn't have been floated out in a let-binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems
by GHC 02 Dec '16

02 Dec '16

#12865: POSIX osDecommitMemory has nasty compatibility problems ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `osDecommitMemory` in `rts/posix/OSMem.c` currently does the following, {{{#!c #ifdef MADV_FREE // Try MADV_FREE first, FreeBSD has both and MADV_DONTNEED // just swaps memory out r = madvise(at, size, MADV_FREE); #else r = madvise(at, size, MADV_DONTNEED); #endif if(r < 0) sysErrorBelch("unable to decommit memory"); }}} As it turns out, the Linux kernel as of 4.5 supports `MADV_FREE`. This means that binary distributions built in such environments will use `MADV_FREE`, even if running on an older kernel that does not support this advice. Ultimately this means that any attempt to decommit will fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9184: Allow the use of Python 3 when building GHC
by GHC 02 Dec '16

02 Dec '16

#9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | 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: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24