May 2017 - ghc-tickets

[GHC] #12499: Support multiple library import libs
by GHC 02 Jun '17

02 Jun '17

#12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our implementation of import libraries only support single library import libs. These are by far the most common ones. However it is possible to make multi library import libraries. E.g. one import library pointing to multiple dlls. `binutils` correct supports these and with #5987 GHC will be relying on them to work. It makes sense that we are able to load them in GHCi as well. This will be required for a fully working dynamic GHC on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13762: TypeInType is not documented in the users' guide flag reference
by GHC 02 Jun '17

02 Jun '17

#13762: TypeInType is not documented in the users' guide flag reference -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least, not as of http://git.haskell.org/ghc.git/blob/09d5c993aae208e3d34a9e715297922b6ea42b3…. We should fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12237: Constraint resolution vs. type family resolution vs. TypeErrors
by GHC 01 Jun '17

01 Jun '17

#12237: Constraint resolution vs. type family resolution vs. TypeErrors -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Via http://stackoverflow.com/q/37769351/477476, given the following setup: {{{#!hs {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-} {-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, UndecidableInstances #-} import Data.Proxy import GHC.TypeLits type family TEq a b where TEq a a = a TEq a b = TypeError (Text "TEq error") type family F a where F () = () F (a, b) = TEq (F a) (F b) F a = TypeError (Text "Unsupported type: " :<>: ShowType a) }}} and the following usages of `F` and `TEq`: {{{#!hs class (repr ~ F a) => C repr a foo :: (C (F a) a) => proxy a -> () foo _ = () main :: IO () main = print $ foo (Proxy :: Proxy (Int, ())) }}} This results in {{{ * No instance for (C (TEq (TypeError ...) ()) (Int, ())) arising from a use of `foo' * In the second argument of `($)', namely `foo (Proxy :: Proxy (Int, ()))' In the expression: print $ foo (Proxy :: Proxy (Int, ())) In an equation for `main': main = print $ foo (Proxy :: Proxy (Int, ())) }}} but it would be preferable to bail out earlier when `F Int` is resolved to `TypeError ...` instead of propagating that all the way to the `C` constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13771: ghc fails to build on openSUSE
by GHC 01 Jun '17

01 Jun '17

#13771: ghc fails to build on openSUSE --------------------------------------+--------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The gcc on openSUSE defaults to -pie and reverting that fixes the build. The gcc does not set any define with -pie or -no-pie. The -no-pie flag is detected but the build fails nonetheless. Adding the PIC flag does not help: {{{ @@ -3650,6 +3650,7 @@ default_PIC :: Platform -> [GeneralFlag] default_PIC platform = case (platformOS platform, platformArch platform) of (OSDarwin, ArchX86_64) -> [Opt_PIC] + (OSLinux, ArchX86_64) -> [Opt_PIC] (OSOpenBSD, ArchX86_64) -> [Opt_PIC] -- Due to PIE support in -- OpenBSD since 5.3 release -- (1 May 2013) we need to }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13719: checkFamInstConsistency dominates compile time
by GHC 31 May '17

31 May '17

#13719: checkFamInstConsistency dominates compile time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13092, #13099, | #12191 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm looking into compile time issues on our internal code base. `checkFamInstConsistency` takes 50% of all compile time for `:load` in `ghci` for us. I've created a synthetic test case that approximates the issue and in which compiling 300 modules with one small data type each takes 65s total, and `checkFamInstConsistency` is 87% of that and 94.1% of allocations. `checkFamInstConsistency` is run to ensure consistency of a type family associated with Generics, but that's only semi-relevant. To reproduce: {{{ ./gen.sh ./inplace/bin/ghc-stage2 -keep-tmp-files DummyLevel3M100.hs }}} Profile with some relevant cost centres: https://phabricator.haskell.org/P150 The next step is to look into implementing: https://ghc.haskell.org/trac/ghc/ticket/13092#comment:14 I also plan to add this test case to the codebase. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12820: Regression around pattern synonyms and higher-rank types
by GHC 30 May '17

30 May '17

#12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.1 accepts, but HEAD rejects: {{{#!hs {-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-} module Bug where pattern P :: (forall a. a -> a) -> String pattern P x <- (\ _ -> id -> x) }}} (Sidenote: kudos to the parser on figuring out my view pattern.) HEAD gives this error: {{{ Bug.hs:6:30: error: • Couldn't match expected type ‘forall a. a -> a’ with actual type ‘a0 -> a0’ • In the declaration for pattern synonym ‘P’ • Relevant bindings include x :: a0 -> a0 (bound at Bug.hs:6:30) }}} The code looks correct to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12908: Tuple constraints refactoring seems to regress performance considerably
by GHC 30 May '17

30 May '17

#12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: performance | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ffc21506894c7887d3620423aaf86bc6113a1071 seems to cause compiler runtime regression as large as 15%. This deserves some attention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13769: T9405 sporadic failure
by GHC 30 May '17

30 May '17

#13769: T9405 sporadic failure -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- I just got a failure on travis with T9405 on https://travis- ci.org/ghc/ghc/builds/237325270. The error: {{{ --- /dev/null 2017-05-29 08:06:46.967079000 +0000 +++ /tmp/ghctest-eo4toy/test spaces/./rts/T9405.run/T9405.run.stderr.normalised 2017-05-29 23:20:55.665885000 +0000 @@ -0,0 +1 @@ +/bin/sh: 4: kill: No such process }}} What I suspect happens is that under some scheduling and with CPU contention, the test instead of timing out just finishes normally. Perhaps increasing the sleep time from `2s` should be enough to mitigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13705: Failure of improvement for type-family dependencies
by GHC 29 May '17

29 May '17

#13705: Failure of improvement for type-family dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE TypeFamilyDependencies #-} data D x type family F t = s | s -> t type instance F (D t) = D (F t) f :: F s -> () f _ = () g :: D (F t) -> () g x = f x }}} which was presented in [https://mail.haskell.org/pipermail/haskell- cafe/2016-October/125375.html this email] from Clinton Mead. It yields {{{ Tx.hs:14:9: error: • Couldn't match expected type ‘F s0’ with actual type ‘D (F t)’ The type variable ‘s0’ is ambiguous }}} But it should work fine -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13705> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13695: Highly nested UNPACKed data causes panic
by GHC 29 May '17

29 May '17

#13695: Highly nested UNPACKed data causes panic ----------------------------------------+--------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 3990 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- See attached source files. I get the following error: {{{ [3 of 3] Compiling Data.BigWord ( src/Data/BigWord.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/Data/BigWord.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170505 for x86_64-unknown-linux): urk! lookup local fingerprint D:R:DoubleWordDoubleWord2 [cESifd :-> (BigWord2, acd0b93ce6ccc191df910f3c0527af52), cESife :-> (BigWord3, c2394bb5a6246cea8260b764c4645609), cESiqK :-> (BigWord4, dfeb99d5c409e91fe7084935101bb1a8), cESiqT :-> (R:DoubleWordDoubleWord3, 00000000000000000000000000000000), cESiqV :-> (D:R:DoubleWordDoubleWord4, 00000000000000000000000000000000), cESir1 :-> (D:R:BigWord4, 7d2736129b3a85c7e71bc1954bb41ec0), dESiqK :-> (BigWord4, d51a0117843c625086a534a6e4b47d85), iESiqK :-> (BigWord4, 139d5d98471af07fbafb30541b5ec225), iESiqX :-> ($WBigWord4, df51c2cc8c85fdd30898a16f2568c91a)] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:508:37 in ghc:MkIface }}} I need to use ghc-8.2.1 because it seems to be the earliest version that contains the fixes in [https://ghc.haskell.org/trac/ghc/ticket/3990] without which the UNPACKs will be ignored. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20