February 2015 - ghc-tickets

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 11 Feb '15

11 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550 | -------------------------------------+------------------------------------- Comment (by goldfire): Just took a quick look at this, as I was in the area. This will take some plumbing to implement right, sadly. The problem is that the type family reduction happens in the bowels of the flattening algorithm. To do this right, we need to update the `CtLoc` of the relevant constraint, but there's no good way to do that from the middle of the flattener. Two ways forward: 1. Install the plumbing. I vote that this should be a new `FlatM` monad (built on `TcS`) that allows updating of the `CtLoc` currently stored in the `FlattenEnv`. `FlatM` would gather up the `FlattenEnv` stuff, the `runFlatten` stuff, and this new type-family-depth-counting stuff. Seems like enough stuff to make it a new structure. 2. Have a local counter just for the new, eager type family reduction. We have access to `DynFlags`, of course, so we can check if the number of eager reductions is more than requested. We can even add the number of eager reductions to the number of reductions done previously. What we can't do is record the number of eager reductions. So, if the stack depth were 200, then this plan (2) would allow, say, 190 eager reductions at one go, then some other solving, and then another 190 eager reductions, and then some solving, and so on. The depth is still bounded, but it makes it nigh impossible for a programmer to relate their choice of `-ftype- function-depth` to GHC's behavior, as it all depends on where the reduction takes place. Thoughts? Still no promises on getting to this for real before March, I'm afraid, especially for option 1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 11 Feb '15

11 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550 | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: simonpj => goldfire * related: => #8550 * milestone: 7.12.1 => 7.10.1 Comment: I just noticed that I had been asked to do this, and I think it would be nice in 7.10. However, the fix would potentially be user-facing: A type-family-heavy program that compiles on 7.10.1RC2 might need to set `-ftype-function- depth` after the fix. Is that acceptable at this point? Also, time is very precious for me before Feb. 27. I can get right on this Mar. 2. (See also #8550, which is probably a dup of this bug.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7765: Odd error message for `runghc` with missing `main` function.
by GHC 10 Feb '15

10 Feb '15

#7765: Odd error message for `runghc` with missing `main` function. -------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #414 | module/T7765 | Blocking: | Differential Revisions: Phab:D649 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => module/T7765 * differential: => Phab:D649 * related: => #414 Comment: With Phab:D649, `Main` without `main` is always an error, regardless of the mode of operation: `ghc`, `ghci` or `runhaskell` (=`ghc -e main`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7765#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #414: GHC does not eforce that Main exports main
by GHC 10 Feb '15

10 Feb '15

#414: GHC does not eforce that Main exports main -------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T414 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: mod174 => module/T414 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/414#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1103: Japanese Unicode
by GHC 10 Feb '15

10 Feb '15

#1103: Japanese Unicode -------------------------------------+------------------------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 Component: Compiler | branch (Parser) | Version: 6.6 Resolution: fixed | Keywords: japanese Operating System: Unknown/Multiple | unicode lexical -fglasgow-exts Type of failure: None/Unknown | report-impact Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: japanese unicode lexical -fglasgow-exts => japanese unicode lexical -fglasgow-exts report-impact * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1103#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9213: CPP warnings on ghcautoconf.h
by GHC 09 Feb '15

09 Feb '15

#9213: CPP warnings on ghcautoconf.h ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 cpphs program yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line `# if defined __BIG_ENDIAN__` has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #7103: Compiler panic, when loading wxc in GHCi
by GHC 09 Feb '15

09 Feb '15

#7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: 3658 | Test Case: Related Tickets: #9907, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darthdeus): I ran into the same thing while trying to get the `mysql` package working, where after many changes I was able to get the package to successfully compile on its own, but while linking with a larger application this error essentially killed the deployment, since there doesn't seem to be a way to work around it. Removing the idata$4 section with `--no-idata4` yielded the same error with idata$5, so we tried removing that with `--no-idata5`, but then ran into the same issue with idata$7. ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: Unknown PEi386 section name `.idata$7' (while processing: C:\Haskell\ert\.cabal-sandbox\x86_64-windows- 7\libmysql.a) cabal: Error: some packages failed to install: We also tried modifying dlltool to remove the idata$7 section as well (source https://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/dlltool.c) but without any success. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7103#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10036: Update Cabal before final 7.10 release
by GHC 09 Feb '15

09 Feb '15

#10036: Update Cabal before final 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc2 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC. https://github.com/haskell/cabal/pull/2391 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10020: GHC 7.10 rejects nullary type class with associated data
by GHC 09 Feb '15

09 Feb '15

#10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In GHC 7.8.4, the following code is legal: {{{#!hs {-# LANGUAGE NullaryTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} In GHC 7.10, {{{NullaryTypeClasses}}} was [https://ghc.haskell.org/trac/ghc/ticket/8993 deprecated] in favor of {{{MultiParamTypeClasses}}}. However, running this code on GHC 7.10-rc1: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} results in this error: {{{ NullaryData.hs:4:1: The associated type ‘NullaryData’ mentions none of the type or kind variables of the class ‘NullaryClass’ In the class declaration for ‘NullaryClass’ }}} It's probably related to [https://ghc.haskell.org/trac/ghc/ticket/9167 this earlier bugfix]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10050: template haskell Ppr missing parentheses for SigT
by GHC 09 Feb '15

09 Feb '15

#10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | 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: | -------------------------------------+------------------------------------- {{{#!hs ppr (SigE (VarE (mkName "a")) (SigT (VarT (mkName "x")) (VarT (mkName "k")))) }}} prints as "a :: x :: k". Ghc can't parse that, so I think it should be printed as "a :: (x :: k)" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5