March 2016 - ghc-tickets

[GHC] #11700: pattern match bug
by GHC 13 Jun '16

13 Jun '16

#11700: pattern match bug -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: https://github.com/TobyGoodwin | /odd-ghc-pattern-bug | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With some types built by persistent-template, I'm running into very odd behaviour. Attempting to pull apart a tuple in one go... {{{#!hs let (Entity museKey muse, Entity msgKey msg, Entity fldrKey fldr) = cluster }}} fails (or rather, attempting to use msg or fldr fails) with errors like {{{ Couldn't match expected type ‘Folder’ with actual type ‘Folder’ }}} But splitting the pattern up: {{{#!hs let (a, b, c) = cluster Entity museKey muse = a Entity msgKey msg = b Entity fldrKey fldr = c }}} everything works normally Complete test case here: https://github.com/TobyGoodwin/odd-ghc-pattern- bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11670: Can't infer type
by GHC 13 Jun '16

13 Jun '16

#11670: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ _ mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} Fails with {{{ baldur@Loki:~$ ghci -ignore-dot-ghci /tmp/tLcV.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tLcV.hs, interpreted ) /tmp/tLcV.hs:11:10: error: • No instance for (Storable t) Possible fix: add (Storable t) to the context of an expression type signature: IO t • In a stmt of a 'do' block: s <- peekElemOff (castPtr ptr) 0 :: _ _ In the expression: do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } In an equation for ‘peek’: peek ptr = do { s <- peekElemOff (castPtr ptr) 0 :: _ _; mus <- peekElemOff (castPtr ptr) 1; return (MkCTimeval s mus) } Failed, modules loaded: none. }}} while {{{#!hs {-# LANGUAGE InstanceSigs, PartialTypeSignatures #-} import Foreign.C.Types import Foreign.Storable import Foreign.Ptr data CTimeval = MkCTimeval CLong CLong peek :: Ptr CTimeval -> IO CTimeval peek ptr = do s <- peekElemOff (castPtr ptr) 0 :: _ CLong mus <- peekElemOff (castPtr ptr) 1 return (MkCTimeval s mus) }}} succeeds. Is this expected? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11638: referring to the existential type from a GADT pattern match with a type application
by GHC 12 Jun '16

12 Jun '16

#11638: referring to the existential type from a GADT pattern match with a type application -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11387 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently I can define a GADT like {{{ data T where MkT :: forall a. (Num a, Show a) => T }}} but it's useless on two counts: * At a use of the constructor `MkT`, I can't specify what type `a` I want to pack dictionaries for. (In fact the declaration is an error unless either the constraints are defaultable (as in the case above) or AllowAmbiguousTypes is enabled.) * At a pattern match against `MkT`, I have no way to refer to the type for which dictionaries were packed. The solution is to add a field of type `Proxy a` (possibly strict/unpacked) or `Proxy# a` to `MkT`. But these options are all a bit verbose and each have minor drawbacks. I had hoped that TypeApplications would address the two points above directly. * At a use of the constructor `MkT`, specify the type with a type application `MkT @a`. This part works as of 90f35612f16ff9cb2466cc936f12e748402abb85. * At a pattern match against `MkT`, I would like to be able to match the type directly like this: {{{ f :: T -> String f t = case t of MkT @a -> show (0 :: a) }}} This is the feature request. Note that, while this may be stressful for the parser due to as-patterns, I don't think there is any actual ambiguity as long as (1) type applications only appear on constructors, not variables, and (2) all type applications appear before any value-level fields of the constructor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11204: Recompilation checking stochastically broken on Darwin
by GHC 12 Jun '16

12 Jun '16

#11204: Recompilation checking stochastically broken on Darwin ----------------------------------------+---------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The `retc001` test usually fails on Darwin. Unfortunately, it also sometimes passes. Failures look like this, {{{ =====> retc001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory retc001 </dev/null > retc001.run.stdout 2> retc001.run.stderr Actual stderr output differs from expected: --- ./retc001.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ‘B’ does not export ‘foo’ \ No newline at end of file Actual stdout output differs from expected: --- ./retc001.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -3,5 +3,3 @@ [3 of 3] Compiling Main ( C.hs, nothing ) Middle End -[2 of 3] Compiling B ( B.hs, nothing ) -[3 of 3] Compiling Main ( C.hs, nothing ) [B changed] \ No newline at end of file *** unexpected failure for retc001(normal) }}} I suspect the problem is mtime resolution as if I apply the following patch it almost always passes, {{{ diff --git a/testsuite/tests/driver/retc001/Makefile b/testsuite/tests/driver/retc001/Makefile index a3cf6eb..bb1eca8 100644 --- a/testsuite/tests/driver/retc001/Makefile +++ b/testsuite/tests/driver/retc001/Makefile @@ -20,5 +20,6 @@ retc001: clean echo 'Middle' '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite-interface --make C.hs echo 'End' + sleep 1 cp B2.hs B.hs -'$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- interface --make C.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11204> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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 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 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