June 2017 - ghc-tickets

[GHC] #13872: Strange Typeable error message involving TypeInType
by GHC 08 Jul '17

08 Jul '17

#13872: Strange Typeable error message involving TypeInType -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I originally discovered this when tinkering with #13871. This program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo where import Data.Kind import Data.Typeable data Foo (a :: Type) (b :: Type) where MkFoo :: (a ~ Int, b ~ Char) => Foo a b data family Sing (a :: k) data SFoo (z :: Foo a b) where SMkFoo :: SFoo MkFoo f :: String f = show $ typeOf SMkFoo }}} Fails in GHC 8.0.1, 8.0.2, and 8.2 (after applying Phab:D3671) with a rather unsightly error message: {{{ GHCi, version 8.3.20170624: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:19:12: error: • No instance for (Typeable <>) arising from a use of ‘typeOf’ • In the second argument of ‘($)’, namely ‘typeOf SMkFoo’ In the expression: show $ typeOf SMkFoo In an equation for ‘f’: f = show $ typeOf SMkFoo | 19 | f = show $ typeOf SMkFoo | ^^^^^^^^^^^^^ }}} I'm not sure what this mysterious `<>` is, but I'm pretty sure it shouldn't be making an appearance here. (See also #13780, where `<>` also makes a surprise guest appearance.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13871: GHC panic in 8.2 only: typeIsTypeable(Coercion)
by GHC 08 Jul '17

08 Jul '17

#13871: GHC panic in 8.2 only: typeIsTypeable(Coercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code works fine in GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo where import Data.Kind data Foo (a :: Type) (b :: Type) where MkFoo :: (a ~ Int, b ~ Char) => Foo a b data family Sing (a :: k) data SFoo (z :: Foo a b) where SMkFoo :: SFoo MkFoo }}} But in GHC 8.2 and HEAD, it panics: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170622: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170622 for x86_64-unknown-linux): typeIsTypeable(Coercion) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13739: Very slow linking of profiled executables
by GHC 07 Jul '17

07 Jul '17

#13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed. I don't have a minimal test case. Testing on cabal head source tree {{{ cabal --version >cabal-install version 2.1.0.0 >compiled using version 2.1.0.0 of the Cabal library cabal new-configure --enable-profiling --enable-newer --with- ghc=/opt/ghc-8.2.1/bin/ghc cabal build cabal-install # hit Ctrl-C during linking time cabal build cabal-install }}} gives real 1m54.833s user 1m52.936s sys 0m1.620s doing the same with 8.0.2 links in less than a second -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec
by GHC 06 Jul '17

06 Jul '17

#13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec -------------------------------------+------------------------------------- Reporter: timmyjose | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: parsec, | Operating System: MacOS X ghc8.0.2, macOS Sierra | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am working through "Create your own Scheme in 48 hours", and the following program: {{{ $ cat SimpleParser.hs import Text.ParserCombinators.Parsec hiding (spaces) symbol :: Parser Char symbol = anyOf "!$%&|*+-/:<=?>@^_^~#" }}} causes GHC to crash and burn with a panic message. Please find the details as follows: ** PLATFORM and OS DETAILS ** {{{ $ sw_vers ProductName: Mac OS X ProductVersion: 10.12.2 BuildVersion: 16C67 $ uname -a Darwin <elided> 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 }}} ** GHC and Parsec version** {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 $ ghc-pkg list | grep -i parsec attoparsec-0.13.1.0 parsec-3.1.11 }}} ** crash error message ** {{{ $ ghc -v3 SimpleParser.hs Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.0.2-x86_64/usr/lib/ghc-8.0.2/package.conf.d/package.cache Using binary package database: /Users/<elided>/.ghc/x86_64-darwin-8.0.2/package.conf.d/package.cache loading package database /Library/Frameworks/GHC.framework/Versions/8.0.2-x86_64/usr/lib/ghc-8.0.2/package.conf.d loading package database /Users/<elided>/.ghc/x86_64-darwin-8.0.2/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /Library/Frameworks/GHC.framework/Versions/8.0.2-x86_64/usr/lib/ghc-8.0.2/package.conf.d loading package database /Users/z0ltan/.ghc/x86_64-darwin-8.0.2/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *SimpleParser.hs !!! Chasing dependencies: finished in 0.62 milliseconds, allocated 0.337 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-06-28 09:58:23 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude), (Nothing, Text.ParserCombinators.Parsec)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file SimpleParser.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( SimpleParser.hs, SimpleParser.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.20 milliseconds, allocated 0.134 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] anyOf_a1lw :: t_a1lv[tau:1] (CHoleCan: anyOf)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13889> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13894: isByteArrayPinned# should consider BF_LARGE
by GHC 04 Jul '17

04 Jul '17

#13894: isByteArrayPinned# should consider BF_LARGE -------------------------------------+------------------------------------- Reporter: winter | 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: -------------------------------------+------------------------------------- First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray#/MutableByteArray#' is movable during safe FFI call, isn't it? If that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me). Currently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33] to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification
by GHC 04 Jul '17

04 Jul '17

#13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 -- Panic.hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE ExistentialQuantification #-} module Panic where import Data.STRef import Control.Monad.ST data A = forall a. A a st :: ST s () st = do A _ <- pure $ A True ref <- newSTRef 1 readSTRef ref pure () }}} {{{ $ ghc Panic.hs [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): StgCmmEnv: variable not found $dMonad_aGQ local binds for: $trModule $tcA $tc'A $tcA1_rSi $tc'A1_rSJ $trModule1_rSK $trModule2_rSL sat_sT5 sat_sT9 sat_sTa Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above module fails to compile, giving the pasted panic message. Without the ApplicativeDo pragma compilation succeeds. Reproduced with GHC 8.0.2 and a recent head, courtesy of nixpkgs: {{{ gp84vpgar3n3rqvkwj47yyhxvsvbsmi6-ghc-8.1.20170106 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13863: -fno-code is broken on package:language-c-quote
by GHC 04 Jul '17

04 Jul '17

#13863: -fno-code is broken on package:language-c-quote -------------------------------------+------------------------------------- Reporter: duog | 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: -------------------------------------+------------------------------------- reported by awson here: [https://github.com/haskell/haddock/issues/640#issuecomment-310442454] I think this is because QuasiQuotes should trigger object code generation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10648: Some 64-vector SIMD primitives are absolutely useless
by GHC 04 Jul '17

04 Jul '17

#10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The primitives `packInt8X64#`, `packWord8X64#`, `unpackInt8X64#`, `unpackWord8X64#` cannot be used because their types include unboxed 64-tuples, but any haskell code using them does not compile due to the 62-tuple limitation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12610: Emit tab warning promptly
by GHC 03 Jul '17

03 Jul '17

#12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs p = let x = 4 [tab]y = 5 in 12 }}} produces `error: parse error on input ‘y’` and nothing else. The problem is caused by a tab appearing to the user to line up `x` with `y` but actually placing `y` in the wrong column. The user typically will scratch their head and then post a question on StackOverflow. There they'll be told to use `-fwarn-tabs`, but ''that option won't help'' (and it's probably already on) because GHC will exit with a parse error before it gets around to giving the warning. I suspect the solution is probably to emit the tab warning in the lexer, but one of the parsing gurus will probably know better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13906: ApplicativeDo doesn't handle existentials as well as it could
by GHC 03 Jul '17

03 Jul '17

#13906: ApplicativeDo doesn't handle existentials as well as it could -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: ApplicativeDo | 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: -------------------------------------+------------------------------------- `ApplicativeDo` doesn't work nicely with existentials or GADTs. This was first considered in #13242, but I think it's worth reconsidering in light of #13875. In particular, we no longer need to think specially about whether a particular pattern match reveals evidence, as any pattern match that does so must necessarily be strict. Simon Marlow explains (in revised, I-think-unmerged, documentation) that {{{#!hs data T where A :: forall a . Eq a => a -> T test = do A x <- undefined _ <- return 'a' _ <- return 'b' return (x == x) }}} will not typecheck because it is first rearranged to {{{#!hs test = (\x _ -> x == x) <$> do A x <- undefined; _ <- return 'a'; return x <*> return 'b' }}} This is weird! The more human-obvious rearrangement would work just fine: {{{#!hs test = do A x <- undefined (\_ _ -> x == x) <$> return 'a' <*> return 'b' }}} How can we get there? I think it's actually easy. Suppose we have {{{#!hs do p1 <- e1 p2 <- e2 p3 <- e3 p4 <- e4 p5 <- e5 e6 }}} Before starting the detailed dependency analysis and such, let's look just at ''which patterns are strict''. If a pattern is strict, then ''every'' following action must be seen as depending on it, and therefore its bindings and evidence can scope over everything else. Let's say that `p3` is strict. Then we can immediately transform the expression to {{{#!hs do p1 <- e1 p2 <- e2 e3 >>= \case p3 -> do p4 <- e4 p5 <- e5 e6 -- if refutable _ -> fail ... }}} and then continue the process in the inner `do` block. If this is done as an initial pass, then further rearrangement doesn't need to consider the possibility of strict patterns; there won't be any. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5