- ghc-tickets - Haskell.org

[GHC] #9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk-win32-2.0-0 (note the -0 suffix)
by GHC 09 Jun '16

09 Jun '16

#9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk- win32-2.0-0 (note the -0 suffix) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: #5289 #1883 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following compilation under Wine (after applying the workarounds described at http://www.haskell.org/haskellwiki/GHC_under_Wine#Code_that_uses_gtk2hs) {{{ cabal install LambdaHack-0.4.99.0 }}} fails with (the full log attached) {{{ Loading package LambdaHack-0.4.99.1 ... ghc.exe: gtk-win32-2.0: Module not found. <command line>: can't load .so/.DLL for: gtk-win32-2.0.dll (addDLL: could not load DLL) }}} The following workaround sidesteps the problem, leading to a correctly running executable (symlinks are not enough). {{{ cp gtk/bin/libgtk-win32-2.0-0.dll gtk/bin/libgtk-win32-2.0.dll cp gtk/bin/libgdk-win32-2.0-0.dll gtk/bin/libgdk-win32-2.0.dll cp gtk/bin/libatk-1.0-0.dll gtk/bin/libatk-1.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/libgio-2.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/pango- cp gtk/bin/libgio-2.0-0.dll gtk/bin/ cp gtk/bin/libpangowin32-1.0-0.dll gtk/bin/libpangowin32-1.0.dll cp gtk/bin/libpangocairo-1.0-0.dll gtk/bin/libpangocairo-1.0.dll cp gtk/bin/libgdk_pixbuf-2.0-0.dll gtk/bin/libgdk_pixbuf-2.0.dll cp gtk/bin/libpango-1.0-0.dll gtk/bin/libpango-1.0.dll cp gtk/bin/libcairo- gtk/bin/libcairo.dll cp gtk/bin/libcairo-2.dll gtk/bin/libcairo.dll cp gtk/bin/libgobject-2.0-0.dll gtk/bin/libgobject-2.0.dll cp gtk/bin/libgmodule-2.0-0.dll gtk/bin/libgmodule-2.0.dll cp gtk/bin/libgthread-2.0-0.dll gtk/bin/libgthread-2.0.dll cp gtk/bin/libglib-2.0-0.dll gtk/bin/libglib-2.0.dll cp gtk/bin/libfontconfig-1.dll gtk/bin/libfontconfig.dll }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset
by GHC 09 Jun '16

09 Jun '16

#10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: | Owner: MetaMemoryT | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Windows Keywords: | Type of failure: Incorrect Architecture: x86_64 | warning at compile-time (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Getting this any time I compile anything. {{{ ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset 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: warning: accept from ws2_32 is linked instead of __imp_accept 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: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp'
by GHC 09 Jun '16

09 Jun '16

#7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.2.1 Comment: This heavily affects the `bitset` package, which includes its own implementations of these, written by Sergei Lebedev. I'm adding a milestone so this doesn't get lost again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7860#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 09 Jun '16

09 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Per SPJ's request, I've reposted some sleuthing I did in [https://phabricator.haskell.org/D2304#67314 the comments] of Phab:D2304. I decided to my changes on the 300-constructor sum type mentioned at the top of this ticket. I manually implemented a `Generic` instance for this datatype three times, and put each one in its own file: * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v1-hs Gen_v1.hs], which contains a `Generic` instance as GHC derives it currently (without the changes in Phab:D2304) * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v2-hs Gen_v2.hs], which is like `Gen_v1.hs` except that it factors out the topmost `M1` in `from`/`to` (i.e., with the changes in Phab:D2304) * [https://gist.github.com/RyanGlScott/e1ef13b59440200e696f5ca0c23dfb8c #file-gen_v3-hs Gen_v3.hs], which is like `Gen_v1.hs` except that it both (1) factors out the topmost `M1` in `from`/`to` and (2) factors out common occurrences of `L1`/`R1` in `to` I compiled each file with `ghc -O2 -v3 +RTS -s` and dumped the results to logs. Here are the highlights: * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v1.txt] * `{terms: 16,282, types: 2,563,921, coercions: 639,012}` * `7,781,716,432 bytes allocated in the heap` * `Total time 8.708s ( 8.719s elapsed)` * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v2.txt] * `{terms: 16,288, types: 2,924,492, coercions: 9,950}` * `4,479,400,544 bytes allocated in the heap` * `Total time 5.580s ( 5.590s elapsed)` * [https://gist.githubusercontent.com/RyanGlScott/e1ef13b59440200e696f5ca0c23d… Gen_v3.txt] * `{terms: 16,288, types: 2,924,492, coercions: 9,950}` * `4,016,934,848 bytes allocated in the heap` * `Total time 4.990s ( 5.006s elapsed)` There is a huge difference between `v1` and `v2`, as suspected. There is a difference between `v2` and `v3` in that it allocated fewer bytes on the heap, but interestingly, `v3` has the exact same number of types and coercions, so I'm not sure where the improvement is coming from. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site
by GHC 09 Jun '16

09 Jun '16

#8510: Clear up what extensions are needed at a Template Haskell splice site ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- Suppose you write {{{ module M where data T = ... $(cleverThFunction ''T) }}} where `cleverThFunction` is some Template Haskell code in a library somewhere. Question: * '''If `cleverThFunction` generates code that uses `GADTs`, or `ConstraintKinds`, or `TypeFamilies` or whatnot, do those language extension flags have to be in force in module M, or only at the definition of `cleverThFunction`?''' Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of `cleverThFunction`, but '''not''' at the splice site. Reason: the client doesn't know or care how `cleverThFunction` works. This decision would be compatible with the handling of overlapping instances. Gergely writes: There are a lot of extensions that simply can't be used with TH: {{{ - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. }}} The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: {{{ - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). }}} The following needs the pragma at the place of splicing: {{{ - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. }}} I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular * Note `ViewPatterns` vs `LambdaCase`. * Note `GADTs` vs `Rank2`. A very interesting example is `ExplicitForAll`. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool too: {{{ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10569: Treat an out-of-scope variable like a typed hole
by GHC 09 Jun '16

09 Jun '16

#10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If we have {{{ f x = x + y }}} GHC currently reports `Not in scope: y`, and halts. It would be cool to treat `y` as a typed hole, so that * The out-of-scope message would give its type * Using `-fdefer-type-errors` we could defer the error to runtime. This was suggested in #5910 [https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 comment 19], and [http://haskell.1045720.n5.nabble.com/fdefer-more-errors-td5809991.html this Haskell Cafe thread] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12167: <<loop>> when zip + unzipping a shadowed Vector type variable
by GHC 08 Jun '16

08 Jun '16

#12167: <<loop>> when zip + unzipping a shadowed Vector type variable -------------------------------------+------------------------------------- Reporter: markog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Main where import Data.Vector.Unboxed (Vector) import qualified Data.Vector.Unboxed as V (|>) :: a -> (a -> b) -> b x |> f = f x main = do s <- do x <- return $ V.fromList [1,2,3,4] :: IO (Vector Int) d <- return $ V.fromList [1,2,3,4] :: IO (Vector Int) let xd :: (Vector Int, Vector Int) xd = V.zip x d |> V.unzip (x,d) = xd -- here is where the error happens -- returning xd works -- removing the shadowing also works in return x print s }}} I do not see how the above code warrants a <<loop>> error as there is really no recursion in it. The linter always complains when I shadow variables, but I often use the above style in F# to reduce the namespace bloat. Shadowing is not a problem when the variables have different types. Is the above really a compiler error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12166: Pattern synonym existential variable confusion
by GHC 08 Jun '16

08 Jun '16

#12166: Pattern synonym existential variable confusion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ponder this: {{{ magic :: Int -> a magic = undefined pattern Silly :: a -> Int pattern Silly a <- (magic -> a) }}} According to the rules for implicit quantification in pattern signatures, the `a` in `Silly`'s type is labeled as existential. That's sensible enough. But what surprised me is that the code is accepted, even though the pattern `(magic -> a)` doesn't bring any existentials into scope. Apparently, GHC is clever enough not to produce a core-lint error, and it actually treats the variable as existential, as witnessed by {{{ foo (Silly x) = x }}} which fails to compile because of skolem-escape. If you change the pattern signature to {{{ pattern Silly :: forall a. a -> Int }}} that changes `a` to be universal, and then `foo` is accepted. I think the original program, with `a` inferred to be existential, should be rejected. (The inference around universal/existential is not at issue. With a signature `pattern Silly :: () => forall a. a -> Int`, the program is still accepted when it shouldn't be.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 08 Jun '16

08 Jun '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: merge Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 08 Jun '16

08 Jun '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"d7933cbc28f4f094eba3d128bc147920f68c965b/ghc" d7933cbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7933cbc28f4f094eba3d128bc147920f68c965b" Show sources of cost centers in .prof This fixes the problem with duplicate cost-centre names that was reported a couple of times before. When a module implements a typeclass multiple times for different types, methods of different implementations get same cost-centre names and are reported like this: COST CENTRE MODULE %time %alloc CAF GHC.IO.Handle.FD 0.0 32.8 CAF GHC.Read 0.0 1.0 CAF GHC.IO.Encoding 0.0 1.8 showsPrec Main 0.0 1.2 readPrec Main 0.0 19.4 readPrec Main 0.0 20.5 main Main 0.0 20.2 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 53 0 0.0 0.2 0.0 100.0 CAF Main 105 0 0.0 0.3 0.0 62.5 readPrec Main 109 1 0.0 0.6 0.0 0.6 readPrec Main 107 1 0.0 0.6 0.0 0.6 main Main 106 1 0.0 20.2 0.0 61.0 == Main 114 1 0.0 0.0 0.0 0.0 == Main 113 1 0.0 0.0 0.0 0.0 showsPrec Main 112 2 0.0 1.2 0.0 1.2 showsPrec Main 111 2 0.0 0.9 0.0 0.9 readPrec Main 110 0 0.0 18.8 0.0 18.8 readPrec Main 108 0 0.0 19.9 0.0 19.9 It's not possible to tell from the report which `==` took how long. This patch adds one more column at the cost of making outputs wider. The report now looks like this: COST CENTRE MODULE SRC %time %alloc CAF GHC.IO.Handle.FD <entire-module> 0.0 32.9 CAF GHC.IO.Encoding <entire-module> 0.0 1.8 CAF GHC.Read <entire-module> 0.0 1.0 showsPrec Main Main_1.hs:7:19-22 0.0 1.2 readPrec Main Main_1.hs:7:13-16 0.0 19.5 readPrec Main Main_1.hs:4:13-16 0.0 20.5 main Main Main_1.hs:(10,1)-(20,20) 0.0 20.2 individual inherited COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN <built-in> 53 0 0.0 0.2 0.0 100.0 CAF Main <entire-module> 105 0 0.0 0.3 0.0 62.5 readPrec Main Main_1.hs:7:13-16 109 1 0.0 0.6 0.0 0.6 readPrec Main Main_1.hs:4:13-16 107 1 0.0 0.6 0.0 0.6 main Main Main_1.hs:(10,1)-(20,20) 106 1 0.0 20.2 0.0 61.0 == Main Main_1.hs:7:25-26 114 1 0.0 0.0 0.0 0.0 == Main Main_1.hs:4:25-26 113 1 0.0 0.0 0.0 0.0 showsPrec Main Main_1.hs:7:19-22 112 2 0.0 1.2 0.0 1.2 showsPrec Main Main_1.hs:4:19-22 111 2 0.0 0.9 0.0 0.9 readPrec Main Main_1.hs:7:13-16 110 0 0.0 18.8 0.0 18.8 readPrec Main Main_1.hs:4:13-16 108 0 0.0 19.9 0.0 19.9 CAF Text.Read.Lex <entire-module> 102 0 0.0 0.5 0.0 0.5 To fix failing test cases because of different orderings of cost centres (e.g. optimized and non-optimized build printing in different order), with this patch we also start sorting cost centres before printing. The order depends on 1) entries (more entered cost centres come first) 2) names (using strcmp() on cost centre names). Reviewers: simonmar, austin, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2282 GHC Trac Issues: #11543, #8473, #7105 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0