- ghc-tickets - Haskell.org

[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 30 May '17

30 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 30 May '17

30 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

[GHC] #11834: GHC master, not compiling on Archlinux
by GHC 29 May '17

29 May '17

#11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- /usr/bin/ld: -r and -pie may not be used together http://lpaste.net/159726 It appears on Archlinux, with GCC version 5.3.0, there's an implicit -pie flag passed to `ld`. I looked into compiler/main/DriverPipeline.hs at joinObjectFiles, it is unconditionally doing "-Wl,-r", thus the error above. One suggested fix on IRC is to modify getCompilerInfo to know if it supports -no-pie, then add it to the flags that are used. I tried and got somewhere lost in compiler/main/DynFlags.hs. (Completely new to GHC) Hopefully someone can figure it out, it seems important for development and I really want to get involved :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13306: Problems with type inference for static expressions
by GHC 29 May '17

29 May '17

#13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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've been running into some difficulties with type inference for static expressions; I suspect not enough type information might be propagated down. Below are a number of tests, all of which compare type inference for `static` with type inference for a function {{{#!hs fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined }}} Apart from syntactic checks, I'd expect `static <expr>` and `fake`Static <expr>` to behave more or less the same, but they don't. Here are some examples: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} module Main where import Data.Proxy import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Setup -------------------------------------------------------------------------------} -- Some kind of non-injective type family type family NonInj a where NonInj Bool = () NonInj Char = () -- To compare against the real static fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined {------------------------------------------------------------------------------- Test 1: identity function -------------------------------------------------------------------------------} f1 :: Proxy a -> NonInj a -> NonInj a f1 Proxy = id f2 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) f2 Proxy = fakeStatic id -- Fails with: -- -- Couldn't match type ‘a0’ with ‘NonInj a’ -- Expected type: NonInj a -> NonInj a -- Actual type: a0 -> a0 -- The type variable ‘a0’ is ambiguous -- f3 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f3 Proxy = static id -- Fails with the same error -- f4 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f4 Proxy = (static id) :: StaticPtr (NonInj a -> NonInj a) {------------------------------------------------------------------------------- Test 2: adding some kind of universe -------------------------------------------------------------------------------} data U :: * -> * where UB :: U Bool UC :: U Char f5 :: U a -> NonInj a -> NonInj a f5 _ = id -- This works just fine f6 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f6 = static f5 -- but if we introduce Typeable .. f7 :: Typeable a => U a -> NonInj a -> NonInj a f7 _ = id -- .. fakeStatic still works f8 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f8 = fakeStatic f7 -- .. but static leads to a weird error: -- No instance for (Typeable a) arising from a use of ‘f7’ -- f9 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) -- f9 = static f7 {------------------------------------------------------------------------------- Test 3: GADT wrapping StaticPtr -------------------------------------------------------------------------------} data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b -- Serializable types can be embedded into Static; here we just support U StaticBase :: U a -> Static (U a) -- this is fine f10 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f10 x = StaticPtr (fakeStatic f5) `StaticApp` (StaticBase x) -- but this fails with -- Couldn't match type ‘NonInj a -> NonInj a’ -- with ‘NonInj a0 -> NonInj a0’ -- Expected type: U a -> NonInj a -> NonInj a -- Actual type: U a0 -> NonInj a0 -> NonInj a0 -- f11 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) -- f11 x = StaticPtr (static f5) `StaticApp` (StaticBase x) -- although in this case we can work around it with a type annotation: -- (note that for f4 above this workaround didn't work) f12 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f12 x = StaticPtr (static f5 :: StaticPtr (U a -> NonInj a -> NonInj a)) `StaticApp` (StaticBase x) {------------------------------------------------------------------------------- End of tests -------------------------------------------------------------------------------} main :: IO () main = putStrLn "Hi" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13765: GHC cannot parse valid Haskell98 whose first identifier is named signature
by GHC 29 May '17

29 May '17

#13765: GHC cannot parse valid Haskell98 whose first identifier is named signature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | 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: -------------------------------------+------------------------------------- This no longer parses in GHC 8.2: {{{ ezyang@sabre:~$ cat A.hs signature = 2 ezyang@sabre:~$ ghc-8.0 -c A.hs A.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ ezyang@sabre:~$ ghc-head -c A.hs A.hs:1:11: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' | 1 | signature = }}} The problem is that signature is only a keyword in the module header and not in the rest of the code, which means that there is a shift/reduce conflict when you have a `signature` at the top of the module. This is fairly benign bug as you can only trigger it when you have no imports; nevertheless, we should fix it. One possibility is to have a completely different parser entry when you are parsing an `hsig` file so that `signature` never occurs in a module header when you parse a normal Haskell file. ISTR this was modestly more irritating to implement but perhaps it is still not too bad. (Note that the shift/reduce conflict still exists, but since you'll never declare a signature without a module header it is essentially irrelevant.) I discovered this when mpickering pointed out that adding 'signature' to the module header increased the number of shift reduce conflicts. (https://github.com/haskell-suite/haskell-src- exts/pull/355#issuecomment-304536290). This wasn't the case in GHC's parser but only accidentally: there is already a shift reduce conflict when you have a top-level Haddock doc block! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13760: Review: Fix test output after 'Some tidying up of type pretty-printing'
by GHC 28 May '17

28 May '17

#13760: Review: Fix test output after 'Some tidying up of type pretty-printing' -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- The commit https://github.com/ghc/ghc/commit/09d5c993aae208e3d34a9e715297922b6ea42b3f updates the output for T7861.stderr so that the test passes after https://github.com/ghc/ghc/commit/ad14efd539377aaf472ad69449dcaf3e679b0e51 Review that fixing the test is the correct option here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13238: Harmonise pretty printing of parens in hsSyn
by GHC 28 May '17

28 May '17

#13238: Harmonise pretty printing of parens in hsSyn -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Phab:D3043 Removes the insertion of parens in the pretty printer for `HsPar`. This is motivated by making it easier to see if there is a problem with the `ppr` round trip capability introduced in #3384. Due to a lack of time, the has not been done for `ParPat` or `HsParTy`. Complete this work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1