November 2014 - ghc-tickets

[GHC] #9111: base should export Typeable instances of its promoted data constructors
by GHC 07 Jan '15

07 Jan '15

#9111: base should export Typeable instances of its promoted data constructors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- As initially reported in #8486, `base` does not export `Typeable` instances for its promoted data constructors, as witnessed by this: {{{ {-# LANGUAGE DataKinds #-} import Data.Typeable x = typeRep (Proxy :: Proxy True) }}} yields {{{ No instance for (Typeable 'True) arising from a use of ‘typeRep’ In the expression: typeRep (Proxy :: Proxy True) In an equation for ‘x’: x = typeRep (Proxy :: Proxy True) }}} It is indeed possible to derive these instances locally with standalone deriving, but that seems very problematic, should multiple modules do that independently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9508: Rename package key
by GHC 03 Jan '15

03 Jan '15

#9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9495: Do What I Mean RULES for foldr2 look shady
by GHC 02 Jan '15

02 Jan '15

#9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment in the source: {{{ The foldr2/right rule isn't exactly right, because it changes the strictness of foldr2 (and thereby zip) E.g. main = print (null (zip nonobviousNil (build undefined))) where nonobviousNil = f 3 f n = if n == 0 then [] else f (n-1) I'm going to leave it though. }}} This rule is intended to allow `foldr2` to fuse with ''either'' argument list. There are thus two problems, one already documented and the other not: 1. The rule can turn working code into non-working code, although this seems to be ''relatively'' unlikely. (The problem the above example is showing is that if the left list ends at the same time the right list bottoms out, the world goes boom. So `foldr2 f [1,2,3,4] (1:2:3:4:undefined)` appears to be a problem. You could argue this is not a big deal, I suppose. 2. The `foldr2/left` and `foldr2/right` rules are not confluent. They are both active in all phases, but if both list arguments are good producers, they will each want to rewrite the expression differently. So if you actually care about which one fuses, you need to explicitly block fusion with one argument using `NOINLINE`, which of course could easily muck up some other optimization. My uninformed opinion: nix the `foldr2/right` rule, and change the documentation to indicate that `foldr2` fuses with its ''left'' argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9847: Remove "Difficulty" field from the Trac
by GHC 29 Dec '14

29 Dec '14

#9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we recently discussed the [[Newcomers]] page on ghc-devs (this thread: https://www.haskell.org/pipermail/ghc- devs/2014-November/007297.html) we ended up with a conclusion that the "Difficulty" field is not very useful. Simon Marlow proposed that we should remove it: https://www.haskell.org/pipermail/ghc- devs/2014-November/007455.html I agree with Simon's opinion - we don't need Difficulty if we have Keywords. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery
by GHC 27 Dec '14

27 Dec '14

#9067: Optimize clearNursery by short-circuiting when we get to currentNursery ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested): {{{ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 36776b9..0311042 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -598,6 +598,11 @@ clearNursery (Capability *cap) ASSERT(bd->gen_no == 0); ASSERT(bd->gen == g0); IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE)); + if (bd == cap->r.rCurrentNursery) { + IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link) + ASSERT(bd->free == bd->start)); + break; + } } } } }}} This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9764: Home package modules silently override available modules from package database
by GHC 27 Dec '14

27 Dec '14

#9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- To see this, define a module with the same name as some module in base. GHC will compile this: {{{ module Data.List where foo = 2 module A where import Data.List x = print foo }}} This behavior is intentional; the most compelling reason of behaving this way is that if you are calling `ghc` without `-hide-all-packages`, some random package you installed which just happened to provide a module name that conflicted with yours could cause your code to stop compiling if we treated the package database and home packages equally. However, this behavior seems undesirable when `-hide-all-packages` is provided; at the very least, it seems like you might want to provide a warning that you're defining a module which conflicts with a module from a package you have exposed. This behavior will be further undesirable when signatures come into the picture. Now, I will want to include a package containing a signature for `A`, and FURTHERMORE I may want to declare a signature `A.hsig` in the local package which augments this signature with some extra declarations I need. Under the current behavior, the externally imported signature is just ignored entirely, even though I wanted them to be merged together. My proposal is to switch the behavior so that we don't prefer home modules if `-hide-all-packages` is provided. What's not great about this proposal is that it adds yet another discrepancy between bare GHC use and GHC use with `-hide-all-packages`. I'm interested to know what people would like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9762: #8696 + #9012
by GHC 27 Dec '14

27 Dec '14

#9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As of the patch for #9012, we create a static reference to an HPC ticks label if and only if it is in the same package, which is correct for building normally, but not for building libraries that are to be loaded piecemeal by GHCi/TH (as was the issue in #8696). See http://lpaste.net/113689 for an example error. I also wonder whether the other cases of `CLabel.labelDynamic` that check for "same package" could result in similar issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work
by GHC 27 Dec '14

27 Dec '14

#9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've got a partial patch: {{{ diff --git a/ghc.mk b/ghc.mk index eedb023..37ef2f2 100644 --- a/ghc.mk +++ b/ghc.mk @@ -719,7 +719,7 @@ ifneq "$(BINDIST)" "YES" ifneq "$(BOOTSTRAPPING_CONF)" "" ifeq "$(wildcard $(BOOTSTRAPPING_CONF))" "" -$(shell echo "[]" >$(BOOTSTRAPPING_CONF)) +$(shell $(GHC_PKG) init $(BOOTSTRAPPING_CONF)) endif endif }}} But I'm dying here: {{{ ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:646: compiler/stage1/build/.depend-v.haskell: No such file or directory ghc/ghc.mk:114: ghc/stage1/build/.depend.haskell: No such file or directory "rm" -f ghc/stage1/build/.depend.haskell.tmp "/home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2" -M -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package-key array_GX4NwjS8xZkC2ZPtjgwhnz -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key direc_1OR7Bu5EIqqJUPTpfzOCIt -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key ghc_GE0xPzNsQzT2p10hpwDwSW -package-key proce_JJ2k66FcGHSLNmYZUkX8Td -package-key unix_4dEexQFispVG782agZacZC -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -dep- makefile ghc/stage1/build/.depend.haskell.tmp -dep-suffix "" -include-pkg- deps ghc/./Main.hs <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) ghc/ghc.mk:114: recipe for target 'ghc/stage1/build/.depend.haskell' failed make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 }}} A bit hard to diagnose due to #9651. Recording this so I don't forget. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9032: Panic with self-import
by GHC 27 Dec '14

27 Dec '14

#9032: Panic with self-import -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I've run into GHC panic with this code: {{{ {-# OPTIONS_GHC -fno-warn-unused-imports #-} module Singletons.Star where import Data.Singletons.Prelude import Data.Singletons.Decide import Data.Singletons.CustomStar import Singletons.Nat import Singletons.Star -- <------- HERE data Vec :: * -> Nat -> * where VNil :: Vec a Zero VCons :: a -> Vec a n -> Vec a (Succ n) $(singletonStar [''Nat, ''Int, ''String, ''Maybe, ''Vec]) }}} This is a test in `singletons` package that leads to a panic when run: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I was unable to minimize the test case. Reproducing requires following steps: 1. Installing latest th-desugar library from github: {{{ git clone https://github.com/goldfirere/th-desugar.git cd th-desugar cabal install }}} 2. Getting latest development version of singletons: {{{ git clone https://github.com/goldfirere/singletons cd singletons git checkout 56734c2bda721cb9a6a3021b901e3b29d6564f0c make tests }}} All should go well. Now you need to edit file `tests/compile-and- dump/Singletons/Star.hs` and uncomment `import Singletons.Star` line. It should be possible to reproduce the bug with: {{{ cd tests/compile-and-dump/ghc -package-name singletons-1.0 Singletons/Star.hs -i../../dist/build -c -XTemplateHaskell }}} It's important to run `make tests` first so that all interface files required by `Star.hs` are in place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol'
by GHC 23 Dec '14

23 Dec '14

#8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' ----------------------------------+------------------------------ Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ Building ekmett's lens package from HEAD (revision 80c1fddf) with the following error fragment: {{{ Last 10 lines of the build log ( /home/kata/.cabal/logs/lens-4.0.log ): [77 of 85] Compiling Data.Vector.Lens ( src/Data/Vector/Lens.hs, dist/build/Data/Vector/Lens.o ) [78 of 85] Compiling Data.Vector.Generic.Lens ( src/Data/Vector/Generic/Lens.hs, dist/build/Data/Vector/Generic/Lens.o ) [79 of 85] Compiling Generics.Deriving.Lens ( src/Generics/Deriving/Lens.hs, dist/build/Generics/Deriving/Lens.o ) [80 of 85] Compiling GHC.Generics.Lens ( src/GHC/Generics/Lens.hs, dist/build/GHC/Generics/Lens.o ) [81 of 85] Compiling System.Exit.Lens ( src/System/Exit/Lens.hs, dist/build/System/Exit/Lens.o ) [82 of 85] Compiling System.FilePath.Lens ( src/System/FilePath/Lens.hs, dist/build/System/FilePath/Lens.o ) [83 of 85] Compiling System.IO.Error.Lens ( src/System/IO/Error/Lens.hs, dist/build/System/IO/Error/Lens.o ) /usr/bin/ld: dist/build/Control/Lens/TH.dyn_o: relocation R_X86_64_PC32 against undefined symbol `lenszm4zi0_ControlziLensziInternalziTH_appsE1zulgo_info' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: lens-4.0 failed during the building phase. The exception was: ExitFailure 1 }}} Full log is attached. I'm not trying to build with shared libraries, or profiling, or anything like that. I can reproduce this failure starting from a fresh Debian testing install as follows: 1. Bootstrap GHC HEAD. {{{ sudo aptitude install ghc=7.6.3-6 happy=1.19.0-1 alex=3.1.0-1 sudo apt-get build-dep ghc cd /var/tmp git clone git://git.haskell.org/ghc.git cd ghc git checkout e01367ff ./sync-all get ./boot ./configure # Adjust the -j option to taste. make -j4 sudo make install }}} 2. Bootstrap cabal-install. {{{ cd /var/tmp wget http://www.haskell.org/cabal/release/cabal-install-1.18.0.2/cabal- install-1.18.0.2.tar.gz -O - | tar xzf - cd cabal-install-1.18.0.2 patch -p3 < cabal-install-ghc-HEAD.patch # see attached sudo aptitude install zlib1g-dev ./bootstrap.sh export PATH=$HOME/.cabal/bin:$PATH cabal update }}} 3. Build lens. {{{ cd /var/tmp git clone https://github.com/ekmett/lens cd lens git checkout 80c1fddf cabal install cpphs cabal install # this fails }}} Using gcc Debian 4.8.2-14, ld 2.24. The GHC fingerprint and output of `ghc --info` is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34