April 2015 - ghc-tickets

[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.
by GHC 27 Jan '16

27 Jan '16

#9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android
by GHC 26 Jan '16

26 Jan '16

#10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Other Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I experimented with building dynamically linked executables on Android, and figured I should record my findings somewhere. (I'm interested in dynamic Haskell libraries because I'd like to eventually get ghci on Android, though obviously that would also require a bunch of packaging work!) Building a GHC with dynamic library support was no major problem, and I could build a dynamically linked "Hello, world" executable too. The problem arose when trying to actually run the executable: I got a message to the effect that there were unresolved symbols (that live in libHSrts) when loading libHSbase. I tried relinking the executable to put libHSrts before libHSbase in the list of NEEDED shared libraries, and now I instead got an error about missing symbols (that live in libHSbase) when loading libHSrts. I then tried rebuilding libHSrts against libHSbase... and then I got the first error again, about missing symbols (that live in libHSrts) when loading libHSbase, while loading libHSrts. I didn't try also rebuilding libHSbase against libHSrts, because at that point the base library would be dependent on the RTS flavor, which we don't really want. It appears based on these tests that the Android dynamic loader only looks for missing symbols in a shared library in the dependencies of that library in a depth-first fashion, while the Linux ld.so seems to do something more like loading every (direct and indirect) dependency of the executable first and then resolving symbol references between them all at once. I didn't fully characterize the Android loader behavior though, and it's possible that if we could remove the references from libHSrts to libHSbase and libHSghc-prim, then we could list libHSrts first among the dependencies of an executable, and hopefully once libHSrts has been loaded, the loader would then use its symbols to resolve references when loading the libHSghc-prim and libHSbase libraries, even without those libraries having NEEDED entries for libHSrts. Removing the references from libHSrts to libHSbase/libHSghc-prim should be fairly mechanical if we can use constructors in the latter libraries (basically emulate dynamic linking by adding a global variable to libHSrts which is a struct holding the addresses of the base/ghc-prim symbols it needs, and have constructors in those libraries fill in those addresses on load). If that doesn't work, another possibility may be to statically link libHSrts (or whatever part of it we need) into the executable and export libHSrts's dynamic symbols so that they can be used by libHSghc-prim (or other Haskell libraries). I also haven't tested whether this kind of mutual recursion between an executable and its shared library dependencies works on Android. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8287: exploring calling convention changes and related engineering for 7.10
by GHC 25 Jan '16

25 Jan '16

#8287: exploring calling convention changes and related engineering for 7.10 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm creating this as a master ticket for systematically exploring and benchmarking (possibly breaking) changes to the GHC calling convention. This work will initially focus on x86/x86_64, but may have larger scope. Goals: 1. if possible, improve performance systematically for code run on recent CPU micro architecture generations (eg sandybridge, haswell, and future extensions like Knights Landing and Skylake), ideally without pessimizing code on other or older x86_64 micro-architectures 2. Try to bring native and llvm codegens closer to feature parity (or at the very least, do not widen their capability gap) 3. a few other pieces too, will amend this ticket as ideas / plans clarify -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9149: Description of openFileBlocking is wrong
by GHC 25 Jan '16

25 Jan '16

#9149: Description of openFileBlocking is wrong ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- The documentation states: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for reading: if we open in non-blocking mode then the open will fail if there are no writers, whereas a blocking open will block until a writer appears. '' but I think this is the wrong way around, and should be: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appears. '' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8325: Pattern guards in anonymous functions
by GHC 25 Jan '16

25 Jan '16

#8325: Pattern guards in anonymous functions ------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing: {{{ (\x y | x > y -> x | otherwise -> something else) }}} Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9708: Type inference non-determinism due to improvement
by GHC 24 Jan '16

24 Jan '16

#9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here's an example that showed up in Iavor's test `TcTypeNatSimple`: {{{ ti7 :: (x <= y, y <= x) => Proxy (SomeFun x) -> Proxy y -> () ti7 _ _ = () }}} From the ambiguity check for `ti7` we get this constraint {{{ forall x y. (x <= y, y <= x) => ( SomeFun x ~ SomeFun alpha , alpha <= y, y <= alpha) }}} where `alpha` is the unification variable that instantiates `x`. Now, from the givens, improvement gives a derived `[D] x~y`, but we can't actually use that to rewrite anything; we have no evidence. From the wanteds we can use improvement in two alternative ways: {{{ 1. (alpha <= y, y <= alpha) => [D] alpha ~ y 2. (x <= y, y <= alpha) => [D] x <= alpha (alpha <= y, y <= x) => [D] alpha <= x And combining the latter two we get [D] (alpha ~ x) }}} It is (2) that we want. But if we get (1) and fix `alpha := y`, we get an error `Can't unify (SomeFun x ~ SomeFun y)`. I think it's a fluke that this test has been working so far; in my new flatten-skolem work it has started failing, which is not unreasonable. What I HATE is that whether type checking succeeds or fails depends on some random choice about which constraint is processed first. The real bug is that the derived Given has no evidence, and can't be used for rewriting. I think Iavor is fixing this deficiency for. I speculate that the same problem might also show up with ordinary type-class functional dependencies, but I have not found a concrete example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10223: Cleanup `mk/build.mk.sample`
by GHC 24 Jan '16

24 Jan '16

#10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp
by GHC 24 Jan '16

24 Jan '16

#8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------------+------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ #!haskell {-# LANGUAGE NoImplicitPrelude #-} module A where }}} {{{ $ ghc-stage2 -prof -c A.hs Top level: Failed to load interface for ‛GHC.Integer.Type’ Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’? Use -v to see a list of the files searched for. }}} I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module. This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module. The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`: {{{ #!diff diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs index 5e0cd65..9836982 100644 --- a/compiler/coreSyn/CorePrep.lhs +++ b/compiler/coreSyn/CorePrep.lhs @@ -56,6 +56,7 @@ import Config import Data.Bits import Data.List ( mapAccumL ) import Control.Monad +import System.IO.Unsafe ( unsafeInterleaveIO ) \end{code} -- --------------------------------------------------------------------------- @@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env else if thisPackage dflags == integerPackageId then return $ panic "Can't use Integer in integer" else liftM tyThingId + $ unsafeInterleaveIO $ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName) mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv }}} This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar. Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10192: Template Haskell crashes when building yesod-core package
by GHC 24 Jan '16

24 Jan '16

#10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is the output when trying to install yesod-core in a sandbox: {{{ Configuring yesod-core-1.4.8.3... Building yesod-core-1.4.8.3... Preprocessing library yesod-core-1.4.8.3... [ 1 of 31] Compiling Yesod.Routes.TH.Types ( Yesod/Routes/TH/Types.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Routes/TH/Types.o ) [ 2 of 31] Compiling Yesod.Routes.TH.Dispatch ( Yesod/Routes/TH/Dispatch.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/Dispatch.o ) [ 3 of 31] Compiling Yesod.Routes.Overlap ( Yesod/Routes/Overlap.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Overlap.o ) [ 4 of 31] Compiling Yesod.Core.TypeCache ( Yesod/Core/TypeCache.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/TypeCache.o ) [ 5 of 31] Compiling Yesod.Routes.Class ( Yesod/Routes/Class.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Class.o ) [ 6 of 31] Compiling Yesod.Routes.TH.RenderRoute ( Yesod/Routes/TH/RenderRoute.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/RenderRoute.o ) [ 7 of 31] Compiling Yesod.Routes.TH.ParseRoute ( Yesod/Routes/TH/ParseRoute.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/ParseRoute.o ) [ 8 of 31] Compiling Yesod.Routes.TH.RouteAttrs ( Yesod/Routes/TH/RouteAttrs.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Routes/TH/RouteAttrs.o ) [ 9 of 31] Compiling Yesod.Routes.TH ( Yesod/Routes/TH.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Routes/TH.o ) [10 of 31] Compiling Yesod.Routes.Parse ( Yesod/Routes/Parse.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Routes/Parse.o ) [11 of 31] Compiling Paths_yesod_core ( dist/dist-sandbox- d1f72a97/build/autogen/Paths_yesod_core.hs, dist/dist-sandbox- d1f72a97/build/Paths_yesod_core.o ) [12 of 31] Compiling Yesod.Core.Internal.Util ( Yesod/Core/Internal/Util.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Util.o ) [13 of 31] Compiling Yesod.Core.Types ( Yesod/Core/Types.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Types.o ) [14 of 31] Compiling Yesod.Core.Class.Handler ( Yesod/Core/Class/Handler.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Class/Handler.o ) Yesod/Core/Class/Handler.hs:25:1: Warning: Module ‘Control.Monad.Trans.Error’ is deprecated: Use Control.Monad.Trans.Except instead Yesod/Core/Class/Handler.hs:56:11: Warning: In the use of type constructor or class ‘Error’ (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:56:54: Warning: In the use of type constructor or class ‘ErrorT’ (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:56:91: Warning: In the use of type constructor or class ‘ErrorT’ (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:79:11: Warning: In the use of type constructor or class ‘Error’ (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" Yesod/Core/Class/Handler.hs:79:52: Warning: In the use of type constructor or class ‘ErrorT’ (imported from Control.Monad.Trans.Error): Deprecated: "Use Control.Monad.Trans.Except instead" [15 of 31] Compiling Yesod.Core.Internal.Request ( Yesod/Core/Internal/Request.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Request.o ) [16 of 31] Compiling Yesod.Core.Internal.Session ( Yesod/Core/Internal/Session.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Session.o ) [17 of 31] Compiling Yesod.Core.Content ( Yesod/Core/Content.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/Content.o ) Yesod/Core/Content.hs:227:27: Warning: In the use of ‘B.breakByte’ (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" Yesod/Core/Content.hs:232:36: Warning: In the use of ‘B.breakByte’ (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" Yesod/Core/Content.hs:235:19: Warning: In the use of ‘B.breakByte’ (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" [18 of 31] Compiling Yesod.Core.Handler ( Yesod/Core/Handler.hs, dist /dist-sandbox-d1f72a97/build/Yesod/Core/Handler.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.1.0 ... linking ... done. Loading package auto-update-0.1.2.1 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.6.0 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. Loading package blaze-builder-0.4.0.1 ... linking ... done. Loading package hashable-1.2.3.2 ... linking ... done. Loading package case-insensitive-1.2.0.4 ... linking ... done. Loading package containers-0.5.6.3 ... linking ... done. Loading package scientific-0.3.3.8 ... linking ... done. Loading package attoparsec-0.12.1.3 ... linking ... done. Loading package http-date-0.0.6 ... linking ... done. Loading package http-types-0.8.6 ... linking ... done. Loading package appar-0.1.4 ... linking ... done. Loading package byteorder-1.0.4 ... linking ... done. Loading package time-1.5.0.1 ... linking ... done. Loading package unix-2.7.1.0 ... linking ... done. Loading package network-2.6.0.2 ... linking ... done. Loading package iproute-1.3.2 ... linking ... done. Loading package simple-sendfile-0.2.18 ... linking ... done. Loading package filepath-1.4.0.0 ... linking ... done. Loading package directory-1.2.2.0 ... linking ... done. Loading package process-1.2.3.0 ... linking ... done. Loading package random-1.1 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package transformers-0.4.3.0 ... linking ... done. Loading package zlib-0.5.4.2 ... linking ... done. Loading package streaming-commons-0.1.10.0 ... linking ... done. Loading package unix-compat-0.4.1.4 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package vault-0.3.0.4 ... linking ... done. Loading package nats-1 ... linking ... done. Loading package semigroups-0.16.2.2 ... linking ... done. Loading package void-0.7 ... linking ... done. Loading package wai-3.0.2.3 ... linking ... done. Loading package warp-3.0.10 ... linking ... done. Loading package ansi-terminal-0.6.2.1 ... linking ... done. Loading package base64-bytestring-1.0.0.1 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package bytestring-builder-0.10.4.1.2 ... linking ... done. Loading package fast-logger-2.3.0 ... linking ... done. Loading package transformers-compat-0.4.0.4 ... linking ... done. Loading package transformers-base-0.4.4 ... linking ... done. Loading package monad-control-1.0.0.4 ... linking ... done. Loading package lifted-base-0.2.3.6 ... linking ... done. Loading package old-locale-1.0.0.7 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package exceptions-0.8.0.2 ... linking ... done. Loading package mmorph-1.0.4 ... linking ... done. Loading package resourcet-1.1.4.1 ... linking ... done. Loading package stringsearch-0.3.6.5 ... linking ... done. Loading package easy-file-0.2.0 ... linking ... done. Loading package binary-0.7.4.0 ... linking ... done. Loading package old-time-1.1.0.3 ... linking ... done. Loading package unix-time-0.3.5 ... linking ... done. Loading package wai-logger-2.2.3 ... linking ... done. Loading package word8-0.1.2 ... linking ... done. Loading package wai-extra-3.0.4.6 ... linking ... done. Loading package dlist-0.7.1.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package pretty-1.1.3.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package aeson-0.8.0.2 ... linking ... done. Loading package blaze-markup-0.7.0.2 ... linking ... done. Loading package blaze-html-0.8.0.2 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package system-filepath-0.4.13.2 ... linking ... done. Loading package system-fileio-0.3.16.1 ... linking ... done. Loading package shakespeare-2.0.4.1 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package path-pieces-0.2.0 ... linking ... done. Loading package mwc-random-0.13.3.0 ... linking ... done. Loading package conduit-1.2.4 ... linking ... done. Loading package conduit-extra-1.1.7.1 ... linking ... done. Loading package monad-loops-0.4.2.1 ... linking ... done. Loading package stm-chans-3.0.0.2 ... linking ... done. Loading package monad-logger-0.3.13.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package cookie-0.4.1.4 ... linking ... done. Loading package cereal-0.4.1.1 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package securemem-0.1.7 ... linking ... done. Loading package crypto-cipher-types-0.0.9 ... linking ... done. Loading package cipher-aes-0.2.10 ... linking ... done. Loading package crypto-random-0.0.9 ... linking ... done. Loading package cprng-aes-0.6.1 ... linking ... done. Loading package entropy-0.3.6 ... linking ... done. Loading package tagged-0.7.3 ... linking ... done. Loading package crypto-api-0.13.2 ... linking ... done. Loading package setenv-0.1.1.3 ... linking ... done. Loading package skein-1.0.9.2 ... linking ... done. Loading package clientsession-0.9.1.1 ... linking ... done. [19 of 31] Compiling Yesod.Core.Widget ( Yesod/Core/Widget.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Widget.o ) [20 of 31] Compiling Yesod.Core.Class.Breadcrumbs ( Yesod/Core/Class/Breadcrumbs.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Class/Breadcrumbs.o ) [21 of 31] Compiling Yesod.Core.Class.Yesod ( Yesod/Core/Class/Yesod.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Core/Class/Yesod.o ) [22 of 31] Compiling Yesod.Core.Json ( Yesod/Core/Json.hs, dist/dist- sandbox-d1f72a97/build/Yesod/Core/Json.o ) [23 of 31] Compiling Yesod.Core.Internal.Response ( Yesod/Core/Internal/Response.hs, dist/dist-sandbox- d1f72a97/build/Yesod/Core/Internal/Response.o ) [24 of 31] Compiling Yesod.Core.Internal.Run ( Yesod/Core/Internal/Run.hs, dist/dist-sandbox-d1f72a97/build/Yesod/Core/Internal/Run.o ) ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfMonadQzuzdczgzgze_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} It's in a fresh installation of GHC-7.8.4, using cabal-install-1.22.2.0. It is worth noting that this works: {{{ cabal sandbox init cabal install yesod-core }}} But this does not: {{{ cabal sandbox init cabal install yesod-core --upgrade-dependencies --force-reinstalls }}} The context where I ran into this problem uses {{{--upgrade- dependencies}}}, and installs yesod-core as a dependency. Let me know if you need more information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10183: Warning for redundant constraints: interaction with pattern matching
by GHC 24 Jan '16

24 Jan '16

#10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Herbert gives this example: {{{ {-# LANGUAGE GADTs, DataKinds, TypeOperators, UnicodeSyntax #-} import GHC.TypeLits data List l t where Nil ∷ List 0 t (:-) ∷ t → List l t → List (l+1) t head' ∷ (1<=l) ⇒ List l t → t head' (x :- _) = x }}} We get the warning {{{ typelits1.hs:9:9: Warning: Redundant constraint: 1 <= l In the type signature for: head' ∷ (1 <= l) ⇒ List l t → t }}} But of course the warning is not redundant if we want to exclude the `(head' Nil)` case. Here's an example that doesn't depend on `TypeLits`: {{{ data T a where TT :: T True TF :: T False f :: T True -> Bool f TT = True g :: (a ~ True) => T a -> Bool g TT = True }}} Here `f` compiles fine, but `g` warns about a redundant constraint! And indeed the evidence for `(a~True)` is not used in the code for `g`. But that evidence is used to prove that the un-matched pattern `(g TF)` is unreachable. I'm not sure how to fix this. Bother. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4