November 2013 - ghc-tickets

[GHC] #8577: Polymorphism and typed TH
by GHC 05 Dec '13

05 Dec '13

#8577: Polymorphism and typed TH ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- Consider {{{ data A a = A x = [||A||] y = x :: Q (TExp (A Int)) }}} `$$x` is given type `A a`, as expected. However, `$$y` is also given type `A a`. I would expect it to be `A Int`. In other words, given `p :: Q (TExp T1), $$p :: T2` I think GHC should verify the equation `T1 ~ T2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8580: Integer size mismatch errors
by GHC 05 Dec '13

05 Dec '13

#8580: Integer size mismatch errors -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- There is an integer size mismatch in `rts/Stats.c` that causes validation to fail when `size_t /= W_`. This patch adds casts to fix the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2
by GHC 05 Dec '13

05 Dec '13

#8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 ------------------------------+-------------------------------------------- Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: MacOS X Keywords: | Type of failure: GHC doesn't work at all Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8561 | ------------------------------+-------------------------------------------- A recent update to the RTS uses the GCC builtin function `__builtin___clear_cache`. This function was introduced in GCC 4.3. In older GCCs that don't have this builtin function, it's treated as an undefined function, leading to a link-time error. My system has GCC 4.2.1, bundled with XCode 3.2.6. The function is called from `rts/sm/Storage.c`. It seems that x86 architectures don't need a cache flush, so a possible fix is to do nothing on GCC < 4.3.6 on x86 architectures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8576: Improve deriving error messages
by GHC 03 Dec '13

03 Dec '13

#8576: Improve deriving error messages -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Instead of {{{ No instance for (Eq (Int -> Bool)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} for {{{ data Foo = Foo Int (Int -> Bool, Bool) deriving Eq }}} we want something like {{{ No instance for (Eq (Int -> Bool)) arising from the second field of the constructor Foo Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} where we tell the user more precisely from where in its data type the problem comes from. Should be possible by beefing up `CtOrigin`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails
by GHC 02 Dec '13

02 Dec '13

#8567: Poor error message when GeneralizedNewtypeDeriving fails ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I try to compile this silly module: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} module Bug where class C a where meth :: a -> F a type family F a type instance F Int = Bool type instance F Age = Char instance C Int where meth = (> 0) newtype Age = MkAge Int deriving C }}} Then, I get this output: {{{ Bug.hs:16:12: No instance for (GHC.Types.Coercible Bool Char) because ‛Bool’ and ‛Char’ are different types. arising from a use of ‛GHC.Prim.coerce’ In the expression: GHC.Prim.coerce (meth :: Int -> F Int) :: Age -> F Age In an equation for ‛meth’: meth = GHC.Prim.coerce (meth :: Int -> F Int) :: Age -> F Age In the instance declaration for ‛C Age’ }}} What a confusing error message! Of the 9 lines of error, only 3 make sense: the line number (which is correct, at the line number of my `deriving` statement), saying that `Bool` and `Char` are different, and the conclusion that we're in an instance declaration. This might be better: {{{ Bug.hs:16:12: Cannot coerce from ‛Bool’ to ‛Char’ because ‛Bool’ and ‛Char’ are different types arising from the need to coerce ‛Int -> F Int’ to ‛Age -> F Age’ In the instance declaration for ‛C Age’ generated automatically through GeneralizedNewtypeDeriving To see the code I am typechecking, use -ddump-deriv }}} I actually went ahead and tried to fix this myself, but it's unclear to me what the best implementation plan for such an error message is. The code in !TcDeriv generates `HsSyn RdrName` and then renames it to `HsSyn Name`, but that code then gets sent through the normal type-checking pipeline. That pipeline builds up the error-reporting context without much heed to the fact that GHC itself generated the code. So, while I'm sure I could hack away long enough to get the error message to come out right, I'm equally sure that the resulting code would make people want to cry. Any advice? Or does someone with a better perspective want to take a stab? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8275: Loopification breaks profiling
by GHC 02 Dec '13

02 Dec '13

#8275: Loopification breaks profiling ----------------------------------+---------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Profiling is currently broken in HEAD. Setting `BuildFlavour = prof` in `build.mk` leads to a segfault during build. After reverting d61c3ac186c94021c851f7a2a6d20631e35fc1ba (loopification performed in the code generator) everything builds without problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #8220: Macros / functions for source location
by GHC 01 Dec '13

01 Dec '13

#8220: Macros / functions for source location ------------------------------------+------------------------------------- Reporter: wojteknar | 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 GNAT (Ada compiler) there is a special package with functions (evaluated at compile time) that return source location and enclosing entity name. This is very useful for logging and debugging. I'd love to have something similar in GHC. http://www.radford.edu/~nokie/classes/320/std_lib_html/gnat- source_info.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2233: Overhaul System.Process
by GHC 30 Nov '13

30 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"d95a67012ea30b02144d193254d947cdf5400a9d/process"]: {{{ #!CommitTicketReference repository="process" revision="d95a67012ea30b02144d193254d947cdf5400a9d" Be even more careful with the threads that consume output (#2233) There is a potential deadlock with withCreateProcess in the case that there's an exception: cleanupProcess will try to hClose the various handles, but if another thread holds the Handle lock then that hClose will block. Takano Akio fixed the main case of this (in patch 32223a9ab174c22e939c81e24b6f48223c7cb020) by terminating the process (before closing the handles) This works because terminating the process will eventually cause those other threads to finish and release the Handle lock, so we can hClose. However on Unix terminateProcess is not guaranteed to terminate the process since it uses SIGTERM, which can be handled or ignored. So we have to separately guarantee that the handles can be hClosed, and the simplest way to do this is to ensure that the thread reading from the handles get killed in the case there's an exception. So we change forkWait to withForkWait that will kill off the thread if the body gets an exception. Authored-by: Duncan Coutts <duncan(a)well-typed.com> Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2233: Overhaul System.Process
by GHC 30 Nov '13

30 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"228297ec53e9ee7a1a6a3c5964ca7e89a6474c9b/process"]: {{{ #!CommitTicketReference repository="process" revision="228297ec53e9ee7a1a6a3c5964ca7e89a6474c9b" Drop redundant hFlush & add ignoreSigPipe to hClose This is a follow-up to 79ae975aab5866de38e1a01aca7ac5bd9cde2285 (addressing #2233) Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2233: Overhaul System.Process
by GHC 30 Nov '13

30 Nov '13

#2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"b601209456e13ca3d08faffb7e6771bcb8c1b1b4/process"]: {{{ #!CommitTicketReference repository="process" revision="b601209456e13ca3d08faffb7e6771bcb8c1b1b4" All new sync process functions now terminate on an exception (#2233) Now all the functions that call a process synchronously have the same behaviour. Previously just readProcess, readProcessWithExitCode did this, now callProcess and callCommand do too. If a thread running one of these functions gets an exception, including async exceptions (such as from timeout or killThread), then the external process gets terminated. Introduce a helper function to implement this behaviour. Currently it is not exposed to users, but that could be changed easily. Authored-by: Duncan Coutts <duncan(a)well-typed.com> Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2233#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0