February 2018 - ghc-tickets

[GHC] #14298: Let Template Haskell dynamically add a library against which to link
by GHC 03 Dec '18

03 Dec '18

#14298: Let Template Haskell dynamically add a library against which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | 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: -------------------------------------+------------------------------------- As of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking against them, and then cleaning up any other files. This makes packages like `inline-c` ([https://hackage.haskell.org/package/inline-c] possible, where you can write C snippets in quasiquotes and these can interact with your Haskell code. The user doesn't need to pass extra options to GHC (except to enable the right language extensions), and they don't have to see any of the intermediate generated artifacts. Unfortunately, that breaks down for non C compiler languages. It would be nice for TH to also support directly adding a static library, since then one could * use TH's `runIO` to generate static libraries by calling out to whatever other compilers * add the contents of those libraries via TH * delete the temporary files created in the process (again using `runIO`) * have GHC statically link against the content (from the second bullet point) I'm not sure what the API for this could be, but maybe adding a `StaticLibrary` constructor to the `ForeignSrcLang` data type (so one could use `addForeignFile :: ForeignSrcLang -> String -> Q ()`)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12643: class declaration works in ghci, but not in a file
by GHC 02 Dec '18

02 Dec '18

#12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | Owner: 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 following ghci session prints no errors: {{{ > :set -XStandaloneDeriving -XDeriveGeneric > import GHC.Generics > import Control.Monad.Except > deriving instance Generic (ExceptT e m a) > class F a where f :: Rep (Except String a) x }}} However, when I transfer this to a file: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Control.Monad.Except deriving instance Generic (ExceptT e m a) class F a where f :: Rep (Except String a) x }}} I get a mysterious error: {{{ test.hs:6:17: error: • Couldn't match type ‘Rep (Except String a0)’ with ‘Rep (Except String a)’ Expected type: Rep (Except String a) x Actual type: Rep (Except String a0) x NB: ‘Rep’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall a. F a => forall x. Rep (Except String a) x In the class declaration for ‘F’ }}} If I turn on -fdefer-type-errors, I can verify that the type family indeed reduces far enough for a and x to be arguments to injective types, so I believe GHC should not consider this an error: {{{ > :set -XRankNTypes > :kind! forall a x. Rep (Except String a) x forall a x. Rep (Except String a) x :: * = D1 ('MetaData "ExceptT" "Control.Monad.Trans.Except" "transformers-0.5.2.0" 'True) (C1 ('MetaCons "ExceptT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Data.Functor.Identity.Identity (Either [Char] a))))) x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14668: Ordering of declarations can cause typechecking to fail
by GHC 02 Dec '18

02 Dec '18

#14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 will successfully typecheck: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} data CInst data G (b :: ()) = G class C a where type family F a class (C a) => C' a where type family F' a (b :: F a) -- data CInst instance C CInst where type F CInst = () instance C' CInst where type F' CInst (b :: F CInst) = G b }}} But if the `data CInst` declaration is moved to where it is currently commented out, typechecking fails with this error: {{{ Test.hs:23:18: error: • Expected kind ‘F CInst’, but ‘b’ has kind ‘()’ • In the second argument of ‘F'’, namely ‘(b :: F CInst)’ In the type instance declaration for ‘F'’ In the instance declaration for ‘C' CInst’ | 23 | type F' CInst (b :: F CInst) = G b | }}} However, the data declaration //can// be in the lower position if the kind annotation for its argument is instead written as `data G (b :: F CInst) = G`. This behavior is also exhibited when G is a type family (I believe the sort of type family does not matter, but I know for sure closed and open type families). I was using GHC 8.2.2 when I discovered this, but user `erisco` on `#haskell` confirmed for 8.2.1 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8043: Feature Request : Qualified module exports
by GHC 01 Dec '18

01 Dec '18

#8043: Feature Request : Qualified module exports ------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I quite like the practice of using `-XNoImplicitPrelude` and then defining my own (often per-project) Prelude doing things like: {{{ module MyProject.Prelude ( module P ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) }}} As an extension to the above idea, I would like to add qualified module exports defined so that I can do this: {{{ module MyProject.Prelude ( module P , qualified module T ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) import qualified Data.Text as T }}} so that any file which imports `MyProject.Prelude` will then have all the identifiers that they would normally get if they did: {{{ import qualified Data.Text as T }}} Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14655: Compiled nofib-analyse executable segfaults under windows
by GHC 01 Dec '18

01 Dec '18

#14655: Compiled nofib-analyse executable segfaults under windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Happens in 8.2.2 and HEAD {{{ $ ./nofib-analyse.exe ../log2_range ../log2_range +RTS --generate-crash- dumps Access violation in generated code when reading 0xffffffffffffffff Attempting to reconstruct a stack trace... Frame Code address * 0x12ad980 0x454f0b C:\ghc\msys64\home\Andi\ghc_head\nofib\nofib- analyse\nofib-analyse.exe+0x54f0b * 0x12ada10 0x455515 C:\ghc\msys64\home\Andi\ghc_head\nofib\nofib- analyse\nofib-analyse.exe+0x55515 * 0x12adb80 0x4576f6 C:\ghc\msys64\home\Andi\ghc_head\nofib\nofib- analyse\nofib-analyse.exe+0x576f6 * 0x12adb88 0x44bfcd C:\ghc\msys64\home\Andi\ghc_head\nofib\nofib- analyse\nofib-analyse.exe+0x4bfcd * 0x12adb90 0x5512580 * 0x12adb98 0x9d6e10 C:\ghc\msys64\home\Andi\ghc_head\nofib\nofib- analyse\nofib-analyse.exe+0x5d6e10 * 0x12adba0 0x2 * 0x12adba8 0x53b4f30 Crash dump created. Dump written to: C:\ghc\msys64\tmp\ghc-20180109-171729-25632-48420.dmp }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5)
by GHC 01 Dec '18

01 Dec '18

#14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Linking) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do ` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang? {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc- Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o rts/linker/MachO.c: In function 'ocGetNames_MachO': rts/linker/MachO.c:1532:17: error: error: this statement may fall through [-Werror=implicit- fallthrough=] secArray[i].info->relocation_info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = (MachORelocationInfo*)(oc->image + section->reloff); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 1532 | = (MachORelocationInfo*)(oc->image + section->reloff); | ^ rts/linker/MachO.c:1534:13: error: note: here default: { ^~~~~~~ | 1534 | default: { }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13535: vector test suite uses excessive memory on GHC 8.2
by GHC 30 Nov '18

30 Nov '18

#13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- First noticed [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]. I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow these steps: {{{ $ git clone https://github.com/erikd/vector $ cd vector/ $ cabal install --only-dependencies --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal configure --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal test }}} When building `vector-tests-O2`, GHC will stall when compiling the `Tests.Vector` module. On machines with modest memory allowances (e.g., [https://travis-ci.org/haskell/vector/jobs/218749281#L1270 the machines used on Travis CI]), GHC will be killed with an out-of-memory error after trying to compile `Tests.Vector` for a while. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13535> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 61

[GHC] #14230: Gruesome kind mismatch errors for associated data family instances
by GHC 30 Nov '18

30 Nov '18

#14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14175 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun off from https://ghc.haskell.org/trac/ghc/ticket/14175#comment:9. This program, which can only really be compiled on GHC HEAD at the moment: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C k where data CD :: k -> k -> * instance C (Maybe a) where data CD :: (k -> *) -> (k -> *) -> * }}} Gives a heinous error message: {{{ Bug.hs:11:3: error: • Expected kind ‘(k -> *) -> (k -> *) -> *’, but ‘CD :: (k -> *) -> (k -> *) -> *’ has kind ‘Maybe a -> Maybe a -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^^^^^^^ }}} * We shouldn't be expecting kind `(k -> *) -> (k -> *) -> *`, but rather kind `Maybe a -> Maybe a -> *`, due to the instance head itself. * The phrase `‘CD :: (k -> *) -> (k -> *) -> *’ has kind ‘Maybe -> Maybe a -> *’` is similarly confusing. This doesn't point out that the real issue is the use of `(k -> *)`. Another program in a similar vein: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C a where data CD k (a :: k) :: k -> * instance C (Maybe a) where data CD k (a :: k -> *) :: (k -> *) -> * }}} {{{ Bug.hs:13:3: error: • Expected kind ‘(k -> *) -> *’, but ‘CD k (a :: k -> *) :: (k -> *) -> *’ has kind ‘k -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 13 | data CD k (a :: k -> *) :: (k -> *) -> * | ^^^^^^^^^^^^^^^^^^^^^^^ }}} This error message is further muddled by the incorrect use of `k` as the first type pattern (instead of `k -> *`, as subsequent kind signatures would suggest). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application
by GHC 30 Nov '18

30 Nov '18

#13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Proprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so fast. I'm trying to profile where is the problem, in which calls. But very strange behaviour is there. "total time" of application that is running 30secs to 1min is showing 0.33secs. Even MAIN function is not 100%. Please, see first part of .prof file: Tue Mar 28 15:38 2017 Time and Allocation Profiling Report (Final) app.exe +RTS -N -A40m -qb0 -p -RTS total time = 0.33 secs (325 ticks @ 1000 us, 1 processor) total alloc = 86,317,264 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc MAIN MAIN <built- in> 12.6 2.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8177: Roles for type families
by GHC 29 Nov '18

29 Nov '18

#8177: Roles for type families ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- Now that we have [wiki:Roles roles], it might be helpful to be able to give a role signature for a data/type family. At the moment, data/type family constructors have all parameters conservatively assigned to be role `N`. Thus {{{ data family D a -- Parameter conservatively assumed to be N class C a where op :: D a -> a instance C Int where .... newtype N a = MkN a deriving( C ) -- Rejected }}} The generalised-newtype-deriving clause `deriving( C )` is rejected because `D` might use its parameter at role `N` thus: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} It would be strictly more expressive if we could * '''Declare''' the roles of D's arguments (as we can declare their kinds). E.g. {{{ data family D a@R }}} * '''Check''' that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} I think there is no technical difficulty here. Just a question of doing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41