- ghc-tickets - Haskell.org

[GHC] #7586: :kind command cannot show kind of type synonyms
by GHC 16 Apr '13

16 Apr '13

#7586: :kind command cannot show kind of type synonyms -----------------------------+---------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following illustrates the problem: {{{ Prelude> type T a = Int Prelude> :k T <interactive>:1:1: Type synonym `T' should have 1 argument, but has been given none In a type in a GHCi command: T }}} Undoubtedly, T has a kind, and there's no reason to insist that the type given to the :kind command should be fully applied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7837: Rules involving equality constraints don't fire
by GHC 16 Apr '13

16 Apr '13

#7837: Rules involving equality constraints don't fire ------------------------------------+--------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: equality constraint,rules Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- In the attached program, the "normalize/Double" rule doesn't fire, whereas "normalize'/Double" does. In general, it seems that a rule doesn't fire if it involves discharging an equality constraint that is required by the LHS. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7816: "main function" is not a function
by GHC 16 Apr '13

16 Apr '13

#7816: "main function" is not a function ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- A module without main gives an error: {{{ A.hs:1:1: The function ‛main’ is not defined in module ‛Main’ }}} However, main in Haskell is not a function. This is often a cause of misunderstandings, for example see [http://ircbrowse.net/browse/haskell?q=main+not+function IRC discussions] or [http://conal.net/blog/posts/everything-is-a-function-in-haskell Conal Elliott's "Everything is a function in Haskell"]. I suggest changing this to: {{{ A.hs:1.1: The IO action ‛main’ is not defined in module ‛Main’ }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #6135: Unboxed Booleans
by GHC 15 Apr '13

15 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by benl): Ok, then find the smallest possible program that segfaults, then look at the Cmm and assembly code to see what's changed. You'll particularly want to ensure that the base libraries are built with the original working compiler, but then build only your test programs with the hacked compiler. There is also a "Debugging GHC" guide on the developers wiki. It might be time to learn how to use GDB. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4185: Deriving higher-arity instances for newtype family instances fails
by GHC 15 Apr '13

15 Apr '13

#4185: Deriving higher-arity instances for newtype family instances fails ---------------------------------+------------------------------------------ Reporter: LouisWasserman | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by sjoerd_visscher): DeriveFunctor has the same problem: {{{ data family D x :: * -> * data instance D () a = X a deriving Functor }}} gives {{{ Derived instance `Functor (D ())' requires illegal partial application of data type family D In the data instance declaration for `D' }}} While implementing the instance by hand works fine: {{{ instance Functor (D ()) where fmap f (X a) = X (f a) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4185#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7838: ghc(i) crashes on instance declaration
by GHC 15 Apr '13

15 Apr '13

#7838: ghc(i) crashes on instance declaration -----------------------------+---------------------------------------------- Reporter: alios | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: MultiParamTypeClasses Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ multiple lines, ''no wiki'' {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, ConstraintKinds, UndecidableInstances, FunctionalDependencies, FlexibleInstances #-} {- after declaring the instance instance TS TST TT m where below my ghci crashes on arch linux x86_64, if you comment it out no crash happens. ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): getClassPredTys <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -} module Crash where class T t where type TPI t :: * class (T t, C (TPI t) m (TPI t)) => TC c t m | c -> t class (T t, C (TPI t) m (TPI t)) => TS s t m | s -> t data C i m o data TST data TT instance TS TST TT m where }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7097: linker fails to load package with binding to foreign library
by GHC 15 Apr '13

15 Apr '13

#7097: linker fails to load package with binding to foreign library ----------------------------------+----------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Windows Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: #2283 #3242 #1883 | ----------------------------------+----------------------------------------- Comment(by awson): I'd want to clarify things a bit here. Suppose we have some compiled dll exporting some function `foo`. Suppose we write a client program in C calling this `foo`. Regardless of how this `foo` is prototyped: as bare `foo` or as {{{__declspec(dllimport) foo}}} a client program will happily call it, but depending on a prototype in ''different ways'': in the first case this will be {{{call foo}}} and if this symbol is external a linker will generate a thunk for this `foo` as {{{jmp __imp_foo}}}, in the second case a C compiler always generates {{{call __imp_foo}}}. Thus the single thing matters here: '''which prototype of a function''' was visible to C compiler when it compiled a code calling that function. If that prototype had {{{__declspec(dllimport)}}} attribute attached, a C compiler generated a call against {{{__imp_foo}}}, otherwise - a call against bare {{{foo}}}. GHC FFI of modern era (with no C backend) always generates the second variant AFAIK. This also explains the difference between 32 and 64 GHCs for Windows. 64-bit GHC is distributed with mingw-w64 headers which use {{{__declspec(dllimport)}}} extensively, and many packages fail to compile. 32-bit GHC is distributed with mingw headers which has almost (or entirely?) no {{{__declspec(dllimport)}}} declared APIs. To make 64-bit GHC usable on Windows I manually removed all {{{__declspec(dllimport)}}} from mingw-w64 headers and now it all works smoothly. Hope this helps. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7097#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept.
by GHC 15 Apr '13

15 Apr '13

#7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. ---------------------------------+------------------------------------------ Reporter: PHO | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: 3472 Related: | ---------------------------------+------------------------------------------ Comment(by PHO): Ah, I forgot to tell you that [http://pkgsrc.se/wip/ghc pkgsrc-wip/ghc] has switched to the binary bootstrapping way, so it's ok for me to stop supporting HC bootstrap. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7463#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 15 Apr '13

15 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): I'm looking at the diff and I don't think that I could possibly split it into smaller changes. The problem is that once you change one of the primops to return `Int#`, you have to change them all because they all fall into the same Compare category. And then you need to fix deriving of Eq and Ord. These are the smallest changes I was able to make and have the code compile. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 14 Apr '13

14 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by benl): Work more incrementally. Change just a bit at a time and make sure all the codeGen tests work before doing the next part. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0