April 2016 - ghc-tickets

[GHC] #9010: TemplateHaskell leads to an "unknown symbol" error
by GHC 04 Nov '16

04 Nov '16

#9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code
by GHC 02 Nov '16

02 Nov '16

#11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Aeson.TH data Record = Record { type_ :: Int } $(deriveJSON defaultOptions{ fieldLabelModifier = \x -> case x of "type_" -> "type" _ -> x } ''Record) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): tcMonoExpr _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10221: LLVM does not work on OSX
by GHC 01 Nov '16

01 Nov '16

#10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli@auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9858: Typeable instance for datatype and its promoted constructor is the same
by GHC 26 Oct '16

26 Oct '16

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 119

[GHC] #11339: Possible type-checker regression in GHC 8.0
by GHC 21 Oct '16

21 Oct '16

#11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: -------------------------------------+------------------------------------- The following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: • Couldn't match type ‘f’ with ‘Const [Identity a]’ ‘f’ is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b • In the first argument of ‘t’, namely ‘afb’ In the expression: t afb In a case alternative: _ -> t afb • Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11214: Remove JavaScriptFFI from --supported-extensions list
by GHC 18 Oct '16

18 Oct '16

#11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11108: Weak references related crash
by GHC 17 Oct '16

17 Oct '16

#11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib
by GHC 15 Oct '16

15 Oct '16

#9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`. {{{ module Main where import qualified Codec.Compression.Zlib as Zlib import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Internal as BI import Control.Exception (bracket) import Control.Concurrent import Control.Monad import Control.Exception ( evaluate) import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package import Control.Concurrent.Async ( mapConcurrently) import System.Mem ( performGC ) import Debug.Trace test :: Int -> IO String test _ = do tid <- myThreadId -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100 -- Could also be replaced by: (BL.take (10^7) "/dev/urandom") dat <- BL.readFile "/tmp/testdata" let cbuf = Zlib.compress $ traceChunks tid $ dat s <- evaluate $ sha1 $ Zlib.decompress $ cbuf return $ show s where -- We used this to check whether buffers were reused by different threads, but that -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it -- harder to reproduce possibly because of scheduler effects. In a much larger program -- it could be reproduced more easily without the trace, but in this small example -- tracing seems to cause the right amount of nondeterminism. traceChunks tid bs = BL.fromChunks $ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..] $ BL.toChunks bs showBS (BI.PS ptr off len) = show ptr main = do r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int]) putStrLn $ show $ r where -- Regularly forcing the GC makes the test-case more reproducible. withGCThread io = bracket (forkIO $ forever $ performGC >> threadDelay 1000) killThread (const io) }}} The output should be something like: {{{ ... ThreadId 51:0x00000001091ee010 ThreadId 49:0x00000001091a7010 ... ThreadId 49:0x000000010986f010 zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check) }}} You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different. So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9685: GHC fails to build with mingw32-make on Windows
by GHC 15 Oct '16

15 Oct '16

#9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to be able to build ghc on Windows with mingw32-make which is bundled with the prebuilt gcc package that we are using for the ghc build. mingw32-make might be faster (due to less overhead associated with POSIX compatibility, forks etc.) and more reliable - msys2's make is a bit glitchy because it needs to fork off a lot of processes and sometimes runs into issues with fork(), which should not be a problem for mingw32-make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10437: RunHaskell error in HSExtra on Win64
by GHC 15 Oct '16

15 Oct '16

#10437: RunHaskell error in HSExtra on Win64 -------------------------------------+------------------------------------- Reporter: | Owner: ScottSedgwick | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Windows Keywords: runhaskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I ran the following command, and got this error: {{{ $ runhaskell shakefile.hs clean shakefile.hs: C:\Users\Scott Sedgwick\AppData\Roaming\cabal\x86_64 -windows-ghc-7.8.3\extra-1.2\HSextra-1.2.o: Not x86_64 PEi386 shakefile.hs: shakefile.hs: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Scott Sedgwick\\AppData\\Roaming\\cabal\\x86_64-windows- ghc-7.8.3\\extra-1.2\\HSextra-1.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The shakefile in question looks like this: {{{ import Development.Shake import Development.Shake.FilePath --import System.Info srcFiles = [ "source/main.hs", "source/DBDataStructures.hs", "source/FormatDBData.hs", "source/GetDBData.hs", "source/ParseDBData.hs"] exeFile = "dist/build/mssql-er/mssql-er.exe" depFiles = [ "dependencies/erd/erd.exe", "dependencies/dot/Pathplan.dll", "dependencies/dot/config6", "dependencies/dot/gvc.dll", "dependencies/dot/iconv.dll", "dependencies/dot/libfontconfig-1.dll", "dependencies/dot/libgmodule-2.0-0.dll", "dependencies/dot/libpango-1.0-0.dll", "dependencies/dot/libpangowin32-1.0-0.dll", "dependencies/dot/ltdl.dll", "dependencies/dot/cdt.dll", "dependencies/dot/dot.exe", "dependencies/dot/gvplugin_dot_layout.dll", "dependencies/dot/libcairo-2.dll", "dependencies/dot/libfreetype-6.dll", "dependencies/dot/libgobject-2.0-0.dll", "dependencies/dot/libpangocairo-1.0-0.dll", "dependencies/dot/libpng14-14.dll", "dependencies/dot/zlib1.dll", "dependencies/dot/cgraph.dll", "dependencies/dot/freetype6.dll", "dependencies/dot/gvplugin_pango.dll", "dependencies/dot/libexpat.dll", "dependencies/dot/libglib-2.0-0.dll", "dependencies/dot/libgthread-2.0-0.dll", "dependencies/dot/libpangoft2-1.0-0.dll", "dependencies/dot/libxml2.dll"] copyDep :: FilePath -> Action() copyDep src = do let dst = "dist" </> (dropDirectory1 (dropDirectory1 src)) copyFile' src dst main :: IO() main = shakeArgs shakeOptions $ do want ["deploy"] "clean" ~> do cmd "cabal" "clean" "dist/setup-config" *> \_ -> do need ["mssql-er.cabal"] cmd "cabal" "configure" "--enable-tests" "configure" ~> do need ["dist/setup-config"] exeFile *> \_ -> do need (["configure"] ++ srcFiles) cmd "cabal" "build" "build" ~> do need [exeFile, "test"] "test" ~> do need srcFiles cmd "cabal" "test" "deploy" ~> do need ["build"] mapM_ copyDep depFiles }}} Strangely, if I compile that shakefile using ghc, then run it, it works correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2