October 2014 - ghc-tickets

[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] #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] #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] #9224: Add support for binary integer literals
by GHC 27 May '16

27 May '16

#9224: Add support for binary integer literals -------------------------------------------+------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: literals | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) and base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers via a `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language extension flag/pragma. The change to the lexer is trivial (see attached patch), however I'm stuck on the lexer using a 32-bit feature-mask, of which all 32bits are already taken, and I'd need a 33th bit for the `BinaryLiteralsBit` flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9051: Report heap profile data in eventlog
by GHC 27 May '16

27 May '16

#9051: Report heap profile data in eventlog ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be useful if heap profile data could be reported in the eventlog (either by assigning samples with IDs and recording the sample in the eventlog, or putting the entire profile information in the eventlog). This would make it easier to correlate heap profile data with other events reported by the RTS. It may be hard to stuff the entire sample in the eventlog because the sample is arbitrary size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9399: CPP does not process test case enum01.hs correctly
by GHC 25 May '16

25 May '16

#9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: cpp | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: enum01.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The printTest cpp macro does not seem to be being applied in the test suite test enum01.hs (libraries/base) {{{ > ghci -cpp enum01.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( enum01.hs, interpreted ) enum01.hs:91:3: Not in scope: ‘printTest’ enum01.hs:92:3: Not in scope: ‘printTest’ : }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp
by GHC 25 May '16

25 May '16

#8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 days) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Many parts of MonadComprehensions don't actually require monads instance, the following could do with a `Functor` constraint {{{ fmapM :: Monad m => (a -> b) -> m a -> m b fmapM f xs = [ f x | x <- xs ] }}} and I don't see any reason why the class `MonadZip` (from [http://hackage.haskell.org/package/base-4.4.0.0/docs/Control-Monad- Zip.html Control.Monad.Zip]) requires a `Monad` constraint rather a `Functor` constraint: {{{ class Functor f => FunctorZip f where fzip :: f a -> f b -> f (a,b) fzip = fzipWith (,) fzipWith :: (a -> b -> c) -> f a -> f b -> f c fzipWith f fa fb = fmap (uncurry f) (fzip fa fb) funzip :: f (a,b) -> (f a, f b) funzip fab = (fmap fst fab, fmap snd fab) }}} with the laws {{{ fmap (f *** g) (fzip fa fb) = fzip (fmap f fa) (fmap g fb) fmap (const ()) fa = fmap (const ()) fb ==> funzip (fzip fa fb) = (fa, fb) }}} Same with `Applicative` (see ApplicativeDo): {{{ liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a1 a2 = [ f x1 x2 | x1 <- a1, x2 <- a2 ] }}} The reason I bring this up is because I'm writing a DSL that uses length- indexed vectors whose `Functor` and `FunctorZip` instances are trivial but whose `Monad` instance is [http://stackoverflow.com/questions/5802628 /monad-instance-of-a-number-parameterised-vector complicated] and not need. This proposal shares a similar rationale as ApplicativeDo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9526: Add missing Generic instances in base
by GHC 25 May '16

25 May '16

#9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Most primitive types (`Int`, `Char`, etc.) have a GHC.Generics.Generic instance, but some are missing, such as `Integer` and the various `Word*` data types. We should consistently have instances for all primitive types offered by base, since they are required if you want to derive a Generic instance for any type that contains them. I boldly set the milestone to 7.10 because I naively assume this should be straightforward. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp)
by GHC 23 May '16

23 May '16

#8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Example: {{{ [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "119871672") ,("num_GCs", "100") ,("average_bytes_used", "4388904") ,("max_bytes_used", "12539576") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "27") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.10") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.15") ] [ezyang@hs01 compiler]$ rm T6048.hi [ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "121022912") ,("num_GCs", "100") ,("average_bytes_used", "4022069") ,("max_bytes_used", "11224944") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "25") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.11") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.14") ] }}} It's a slight but present difference: I noticed because one of the perf tests was failing on an initial run of the test suite, but passing when I re-ran it. There are two possible bugs here. One is that our implementation of `-fforce-recomp` is buggy and we shouldn't be reading in the hi file at all if `-fforce-recomp` is on; the other is that we should always clean up interface files before running one of these perf tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9095: make sdist picks up test files
by GHC 22 May '16

22 May '16

#9095: make sdist picks up test files ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I recently ran 'make sdist' and discovered that I my source tarball was nearly a gigabyte large. Closer inspection revealed that sdist had slurped up executable files for tests that I had run at some point. It would be preferable if 'make sdist' did not do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3