January 2015 - ghc-tickets

[GHC] #9937: add updated prefetch API mention to the 7.10 release notes
by GHC 02 Feb '15

02 Feb '15

#9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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/9937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit()
by GHC 02 Feb '15

02 Feb '15

#9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: 9284 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs. The problem has only been observed on OS X, though it probably could occur on Linux OSes as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10027: Importing constructor of associated data type fails
by GHC 02 Feb '15

02 Feb '15

#10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple constructor import associated | Type of failure: None/Unknown data type | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I will base my description on the code you find when searching for "instance PersistEntity" on http://www.yesodweb.com/book/persistent. In summary, the code looks like {{{#!hs instance PersistEntity Person where ... data EntityField Person typ where PersonId :: EntityField Person PersonId PersonName :: EntityField Person String PersonAge :: EntityField Person Int ... }}} This code is generated from TH (see above). I have not tested if it matters that it is generated. A first step could be to test if manually replacing the TH part yields different results. The problem is: When i add this code in one module, do ''not'' create an export list for that module, and try to import the constructors explicitly (i.e. with a list) in a different module, it does not work. I read and tried to follow the description on https://wiki.haskell.org/GHC/Type_families, chapter 4.3. == Testcase 1 == (not really expected to work; still intersting error message) {{{#!hs import MyModuleContainingInstancePerson ( PersonId ) }}} ghc says {{{ ‘PersonId’ is a data constructor of ‘EntityField’ To import it use ‘import’ MyModuleContainingInstancePerson( EntityField( VersionVersion ) ) or ‘import’ MyModuleContainingInstancePerson( EntityField(..) ) }}} == Testcase 2 == (no export list in {{{MyModuleContainingInstancePerson}}}) {{{#!hs import MyModuleContainingInstancePerson ( EntityField(..) ) }}} ghc says {{{ Module ‘MyModuleContainingInstancePerson’ does not export ‘EntityField(..)’ }}} == Testcase 3 == But ''when i do provide'' an export list in {{{MyModuleContainingInstancePerson}}}, like {{{#!hs module MyModuleContainingInstancePerson ( Person(..), EntityField(..) ) where .. }}} Testcase 2 suddenly works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10048: {-# UNPACK #-} support for size-indexed types
by GHC 02 Feb '15

02 Feb '15

#10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I don't know too much of the theory, but it seems to me that `{-# UNPACK #-}` should be able to work for something like this: {{{#!hs data Tup (l::[*]) where Nil :: HList '[] Cons :: e -> {-# UNPACK #-} !(HList l) -> HList (e ': l) }}} This is essentially just `HList` from the `HList` package but strict in the second `Cons` argument. What I would want is for `Tup '[a,b,c]` to be represented in just the same way as `(a,b,c)`. When possible, I'd want the getters/setters/lenses to be optimized to index into the unpacked structure rather than walking along it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10054: Misleading error message from unsaturated type family application
by GHC 01 Feb '15

01 Feb '15

#10054: Misleading error message from unsaturated type family application -------------------------------------+------------------------------------- Reporter: sherman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Operating System: MacOS X Keywords: type | Type of failure: Incorrect families, constraint kinds | warning at compile-time Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This program {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, KindSignatures #-} {-# LANGUAGE TypeFamilies #-} import GHC.Exts (Constraint) data Foo :: (* -> Constraint) -> * -> * where MkFoo :: c a => Foo c a type family Ap (f :: * -> Constraint) (x :: *) :: Constraint where Ap f x = f x test :: Ap Show a => Foo (Ap Show) a test = MkFoo }}} yields the following error message: {{{ [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:13:8: Could not deduce (Ap Show a) arising from a use of ‘MkFoo’ from the context (Ap Show a) bound by the type signature for test :: (Ap Show a) => Foo (Ap Show) a at Test.hs:12:9-36 Relevant bindings include test :: Foo (Ap Show) a (bound at Test.hs:13:1) In the expression: MkFoo In an equation for ‘test’: test = MkFoo Failed, modules loaded: none. }}} I have a hypothesis as to why this error occurs. Because the application of {{{Ap}}} in {{{Ap Show a}}} is fully applied in the context, it reduces to the constraint {{{Show a}}}. However, when error messages describe the typeclass context, they don't reduce type synonyms or type families. However, the {{{Ap Show a}}} that cannot be deduced, despite appearing like a saturated application of {{{Ap}}}, must not be due to the fact that the {{{Ap Show}}} in the argument to the {{{Foo}}} type constructor is partially applied. If the definition of {{{Ap}}} is eta-reduced, the program in fact successfully typechecks. Or, if the result type of {{{test}}} is instead specified as {{{Foo Show a}}}, the program successfully typechecks. If the type variable {{{a}}} is specialized to a concrete type with a {{{Show}}} instance such as {{{Int}}}, the misleading error message still occurs, with {{{Int}}} substituted for {{{a}}}. I am wondering if there might be some way to report the error in a way that brings attention to the fact that the compiler cannot figure out what {{{Ap Show a}}} ''is'' as the constraint that cannot be deduced. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2615: ghci doesn't play nice with linker scripts
by GHC 30 Jan '15

30 Jan '15

#2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: fixed | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hgolden): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2615#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2615: ghci doesn't play nice with linker scripts
by GHC 30 Jan '15

30 Jan '15

#2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hgolden): I have opened a new ticket:10046, so I am closing this ticket again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2615#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2615: ghci doesn't play nice with linker scripts
by GHC 29 Jan '15

29 Jan '15

#2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Jinhui_Chen): Yes, the libc.so is in English. And you are right, I have tried to change the locale momentarily, and it works. {{{ olc <- withCString "C" $ \lc -> c_setlocale 5 lc r <- loadDLL "/usr/lib/libc.so" putStrLn (show r) c_setlocale 5 olc }}} 5 is for LC_MESSAGES. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2615#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2615: ghci doesn't play nice with linker scripts
by GHC 29 Jan '15

29 Jan '15

#2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hgolden): I suspect that the problem is caused by the error message being in a different language. I wonder if it is possible to add code to the patch to change the locale momentarily while in AddDLL and revert it before returning? If this can be done, then the error message would be in the language we are expecting and the result should be to look for the true shared library by scanning the linker script. Of course, this assumes that the linker script is still in English. (I don't know if this is the case.) If the linker script is in a different language, then the problem becomes much harder to solve without identifying the language and selecting the appropriate strings to use in the regular expressions. Jinhui, please attach the text of /usr/lib/libc.so on your test system so we can see what language it is in. Thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2615#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4879: Deprecate exports
by GHC 29 Jan '15

29 Jan '15

#4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D638 -------------------------------------+------------------------------------- Comment (by hvr): for the record, the patch still seems to work: {{{#!hs module M1 ({-# DEPRECATED sort "dont use me" #-}, sort) where import Data.List (sort) }}} {{{#!hs import M1 (sort) main :: IO () main = print (sort "asdasd") }}} {{{ $ ../inplace/bin/ghc-stage2 -Wall --make M2.hs [1 of 2] Compiling M1 ( M1.hs, M1.o ) [2 of 2] Compiling Main ( M2.hs, M2.o ) M2.hs:4:15: Warning: In the use of ‘sort’ (imported from M1, but defined in base-4.8.0.0:Data.OldList): Deprecated: "dont use me" Linking M2 ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4879#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0