May 2016 - ghc-tickets

[GHC] #12003: Improve error message about closed variables
by GHC 09 Jun '16

09 Jun '16

#12003: Improve error message about closed variables -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple StaticPointers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After allowing local bindings in static definitions the following program {{{ {-# LANGUAGE StaticPointers #-} module M where f x = static g where g = h h = x }}} yields the error {{{ ../tmp/M.hs:4:7: error: • ‘g’ is used in a static form but it is not closed. • In the expression: static g In an equation for ‘f’: f x = static g where g = h h = x }}} Where it would be more helpful to get a message like {{{ ../tmp/M.hs:4:7: error: • ‘g’ is used in a static form but it is not closed because it uses ‘h’ which uses ‘x’ which is not let-bound. • In the expression: static g In an equation for ‘f’: f x = static g where g = h h = x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12014: Make it possible to deprecate a method instantiation of a typeclass instance
by GHC 09 Jun '16

09 Jun '16

#12014: Make it possible to deprecate a method instantiation of a typeclass instance -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{ module A where data Foo = Foo instance Eq Foo where -- {-# DEPRECATED (==) "Deprecated for no reason as well" #-} _a == _b = True {-# DEPRECATED (==.) "Deprecated for no reason" #-} (==.) :: Foo -> Foo -> Bool (==.) _a _b = True }}} Deprecating `(==.)` is possible, but it's not possible to deprecate `(==)` of the `Eq Foo` instance. I'd be useful for my use-case of finding out where `Ord Unique` is used, as these would be a potential sources of non-determinism. Currently the best I can do is to remove the instance, get a compile error, suppress it by fixing up the code and repeat for every affected file. I imagine it would also be useful if a method turned out to be a bad idea for a particular type and the library author tried to phase it out. It could be that one method is implementable, but has terrible performance. For my use-case I would be happy with instance level granularity. Related (but not quite the same): * https://ghc.haskell.org/trac/ghc/wiki/Design/DeprecationMechanisms#Classmet… * https://ghc.haskell.org/trac/ghc/wiki/Design/DeprecationMechanisms/TypeClas… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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

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

08 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 08 Jun '16

08 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] #11543: Profiling information ambiguous
by GHC 08 Jun '16

08 Jun '16

#11543: Profiling information ambiguous -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a module M contains two instances of class C with method m and you ask for top level functions to be profiled then you get two profile entries for method m, and you cannot tell which is which. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9034: GHCi panics when given C++ object file on GNU/Linux
by GHC 08 Jun '16

08 Jun '16

#9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include <iostream> extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L<C++ library paths> which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12105: merge MatchFixity and HsMatchContext
by GHC 07 Jun '16

07 Jun '16

#12105: merge MatchFixity and HsMatchContext -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `MatchFixity` was introduced to facilitate use of API Annotations. `HsMatchContext` does the same thing with more detail, but is chased through all over the place to provide context when processing a `Match`. Since we already have `MatchFixity` in the AST, it may as well provide the full context. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12135: Failure to recompile when #include file is created earlier on include path
by GHC 05 Jun '16

05 Jun '16

#12135: Failure to recompile when #include file is created earlier on include path -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally discovered when trying to improve Hadrian, for context see: https://github.com/snowleopard/hadrian/issues/247#issuecomment-222317602 If you create a file {{{Test.hs}}} {{{#!hs #include "a/Test.hs" main = print message }}} And a file {{{a/Test.h}}} {{{#!hs message = 1 }}} Then run and compile with {{{ghc --make -XCPP -Ib;a Main.hs}}} it compiles and runs properly, printing 1. Changing {{{a/Test.h}}} to {{{message = 2}}} then running {{{ghc}}} rebuilds and prints 2. Creating a fresh {{{b/Test.h}}} with {{{message = 3}}} does not cause {{{ghc}}} to recompile, and thus incorrectly still prints 2. Touching {{{Main.hs}}} causes recompilation, and then the correct header file is picked up, resulting in 3 being printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4