April 2018 - ghc-tickets

[GHC] #15052: DeriveAnyClass instances may skip TypeError constraints
by GHC 18 Apr '18

18 Apr '18

#15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In the presence of `TypeError`, one can derive instances with `DeriveAnyClass` that would be rejected otherwise. A simplistic example would be: {{{#!haskell {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) class TypeError ('Text "BOOM") => C a where f :: a -> () f _ = () data T = T deriving(C) }}} Of course, any attempt to use the instance leads to a type-error. However, the instance is rejected right away using a normal instance declaration or StandaloneDeriving. While this is a toy example, it can actually happen when using `Generics` and default-signatures, where one would puts a `TypeError` in an instance head for one of the `Generics` constructors to give a better error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 17 Apr '18

17 Apr '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Azel): I'd like to have a go at this issue, is anyone working on it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop
by GHC 17 Apr '18

17 Apr '18

#12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be
by GHC 17 Apr '18

17 Apr '18

#15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE RecursiveDo #-} module Main where a :: String a = "hello" test :: IO () test = mdo putStrLn a let a = 3 :: Int print a }}} With both GHC 8.2.2 and GHC 8.4.1, it fails with the following error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:10:5: error: • Couldn't match type ‘Int’ with ‘[Char]’ Expected type: String Actual type: Int • In a stmt of an 'mdo' block: rec putStrLn a let a = (3 :: Int) In the expression: mdo rec putStrLn a let a = ... print a In an equation for ‘test’: test = mdo rec putStrLn a let ... print a | 10 | putStrLn a | ^^^^^^^^^^ }}} I would expect it to succeed, with `a` shadowing the top-level definition. The desugared output in the error message tells us what is wrong: it is grouping `putStrLn a; let a = ...` together! If I alter the program to be: {{{#!hs a :: String a = "hello" test :: IO () test = do rec putStrLn a let a = 3 :: Int print a }}} Then it does the Right Thing. Looking at the [https://prime.haskell.org/wiki/RecursiveDo Haskell Prime wiki entry for Recursive Do], this seems to be the relevant bit: > That is, a variable used before it is bound is treated as recursively defined, while in a Haskell 98 do-statement it would be treated as shadowed. I have a more complicated reproduction involving `ST` types and complaints of skolem type variables escaping scope: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE RecursiveDo #-} module Main where import Control.Monad.ST theThing :: ST s () theThing = pure () weirdlyLocal :: ST s () weirdlyLocal = theThing runSTIO :: (forall s. ST s a) -> IO a runSTIO x = pure (runST x) thisWorks :: IO () thisWorks = mdo let weirdlyLocal = theThing runSTIO weirdlyLocal runSTIO weirdlyLocal thisBreaks :: IO () thisBreaks = mdo runSTIO weirdlyLocal let weirdlyLocal = theThing runSTIO weirdlyLocal thisIsFine :: IO () thisIsFine = mdo runSTIO weirdlyLocal let asdf = theThing runSTIO asdf }}} This demonstrates an even more bizarre behavior! If I move the `let` up to the top, then it no longer gets included in a `rec`, and it compiles fine. If I move it under the first statement, then I get this error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:25:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:25:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In a stmt of an 'mdo' block: rec runSTIO weirdlyLocal let weirdlyLocal = theThing • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 25 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ /home/matt/Projects/ghc-repro/src/Main.hs:27:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:27:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In the expression: mdo rec runSTIO weirdlyLocal let weirdlyLocal = ... runSTIO weirdlyLocal • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 27 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11045: Loading temp shared object failed - undefined symbol
by GHC 17 Apr '18

17 Apr '18

#11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While re-compiling [https://github.com/commercialhaskell/stack stack]: {{{ $ stack install --ghc-options -O2 stack-0.1.7.0: configure Configuring stack-0.1.7.0... stack-0.1.7.0: build Preprocessing library stack-0.1.7.0... [30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o ) [31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o ) [32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o ) [33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed] [34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed] [35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o ) [36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed] [37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed] [38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o ) [39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed] [40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed] [41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed] ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package stack-0.1.7.0 using: /home/simon/.stack/setup-exe-cache/setup-Simple- Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 $ git show commit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad Author: Emanuel Borsboom <manny(a)fpcomplete.com> Date: Sun Nov 1 05:21:16 2015 -0800 <snip> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11499: Loading temp shared object failed in GHCi
by GHC 17 Apr '18

17 Apr '18

#11499: Loading temp shared object failed in GHCi --------------------------------------+------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- While trying to launch ghci got the following error: ❯ stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14972: MacOS panic on TH
by GHC 17 Apr '18

17 Apr '18

#14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH. For example: {{{#!hs {-# language TemplateHaskell #-} pure [] main = pure [] }}} Crashes with {{{ $ ./inplace/bin/ghc-stage2 th.hs [1 of 1] Compiling Main ( th.hs, th.o ) ghc-stage2: loadArchive: Failed reading header from `/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist- install/build/gmp' ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180325 for x86_64-apple-darwin): loadArchive "/Users/atheriault/Documents/code/ghc/libraries /integer-gmp/dist-install/build/gmp": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Normally I'd assume I haven't correctly configured something, yet I had no problem building and running GHC on this machine a month or so ago... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14988: Memory strain while compiling HLint
by GHC 17 Apr '18

17 Apr '18

#14988: Memory strain while compiling HLint -------------------------------------+------------------------------------- Reporter: mcandre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to setup a build bot for generating Haskell binaries in an automated fashion, however even with 4 GB of RAM, cabal is unable to build HLint in HardenedBSD. Specifically, GHC is choking on mmap errors while compiling HLint's huge dependency tree. Can we somehow shrink the massive memory usage of GHC, so that common packages HLint can be built on medium-low build bots? Imagine GHC running on a RaspberryPi: You're gonna have a bad time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12982: Missed constant folding oportunities
by GHC 17 Apr '18

17 Apr '18

#12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: | Version: 8.0.1 libraries/hoopl | 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: -------------------------------------+------------------------------------- A work colleague of mine found that some expressions were not being constant folded as expected. For example: {{#!hs module Test where import Data.Int number :: Int64 number = 2 ^ 10 - 3 }}} compiled using: {{{ ghc -O2 -keep-s-file -c test.hs }}} should result in an assembler file containing the constant `1021` but doesn't. However, if I change the above expression to: {{{ number = 1024 -3 }}} then the output assembler files does contain the value `1021`. I did a bit of a search and found some constant folding code in the `hoopl` library, but that doesn't seem to be what GHC actually uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5