March 2014 - ghc-tickets

[GHC] #8266: Dynamic linking on Mac
by GHC 04 Feb '15

04 Feb '15

#8266: Dynamic linking on Mac ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: highest | Version: 7.7 Component: Build | Operating System: MacOS X System | Type of failure: GHC doesn't work at all Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Many dynamic libraries refer to the build tree. (1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g. {{{ % otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base libHSbase-4.7.0.0-ghc7.7.20130909.dylib: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g. {{{ % otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users /Users/kazu/work/ghc/libraries/vector/dist- install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/primitive/dist- install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g. {{{ % otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users /Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc- paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build /libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #8624: -ddump-splices-file
by GHC 19 Jan '15

19 Jan '15

#8624: -ddump-splices-file ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- I am proposing an additional feature, `-ddump-splices-file` that generates a corresponding `.hs.th` file for every `.hs` file that uses Template Haskell. `-ddump-splices` is an invaluable but a frustrating way to look at generated Haskell code. If TH generation were some kind of error message, the current output would make sense. However, TH is generating code that we rely on and would be easier to comprehend if we could see it in a way the most similar to our existing Haskell code. There is a valid complaint that when TH defines something you can't just grep for it, you have to know what TH is defining by reading documentation and imagining something that isn't in front of you. If you have a file `Foo.hs` `-ddump-splices-file` will generate `Foo.hs.th`. Then whenever someone greps after buliding they will find the declaration. If you check these files in they can grep even before building. Similarly, an IDE can show these files as the source of a declaration. Also, if the TH generation changes in some way when a TH function changes, that will be visible. This seems like a relatively easy feature to add. Any pointers on where to get started? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters
by GHC 07 Jan '15

07 Jan '15

#8486: cannot derive new-typeable instances for promoted data types taking parameters ------------------------------------+------------------------------------- Reporter: aavogt | 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: | ------------------------------------+------------------------------------- Hi, The following code shows the issue: {{{ {-# LANGUAGE DataKinds, DeriveDataTypeable, KindSignatures, PolyKinds, StandaloneDeriving #-} import Data.Typeable import GHC.TypeLits data T (a :: [*]) = T deriving (Typeable) t = T :: T [Int, Double] deriving instance Typeable '[] {- *Main> typeOf t <interactive>:24:1: No instance for (Typeable (* -> [*] -> [*]) ((':) *)) arising from a use of ‛typeOf’ In the expression: typeOf t In an equation for ‛it’: it = typeOf t -} }}} ghc7.7-20131004 doesn't allow either of the following: {{{ deriving instance (Typeable a, Typeable b) => Typeable (a ': b) -- or deriving instance Typeable (':) }}} On ghc-7.6 I could write my own `instance Typeable (T a)`, but this has been disabled it seems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8486> 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 24 Dec '14

24 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

[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
by GHC 22 Dec '14

22 Dec '14

#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | 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: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8749: Pattern synonyms crash GHCi
by GHC 18 Dec '14

18 Dec '14

#8749: Pattern synonyms crash GHCi ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ ghci -XPatternSynonyms > let pattern P x = x }}} causes a panic. I understand pattern synonyms are currently unsupported in GHCi, but we should give an error message, not a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG
by GHC 17 Dec '14

17 Dec '14

#8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: integerConstantFolding Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------+------------------------------------------- Hi, with `-DDEBUG` in `GhcStage2HcOpts`, the test integerConstantFolding fails: {{{ =====> integerConstantFolding(normal) 1103 of 3814 [0, 1, 0] cd ./lib/integer && $MAKE -s --no-print-directory integerConstantFolding </dev/null >integerConstantFolding.run.stdout 2>integerConstantFolding.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-11-12 10:54:14.804286745 +0100 +++ ./lib/integer/integerConstantFolding.run.stderr 2013-11-12 15:33:12.384669953 +0100 @@ -0,0 +1,62 @@ +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl{v r3Ok} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl4{v r3Oo} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl8{v r3Os} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl12{v r3Ow} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww1{v r3OO} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl48{v r3P7} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl52{v r3Pb} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl56{v r3Pf} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl60{v r3Pj} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl64{v r3Pn} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl68{v r3Pr} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww2{v r3Pv} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww3{v r3Pw} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww4{v r3PG} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + ww5{v r3PH} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl90{v r3PR} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl94{v r3PV} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl98{v r3PZ} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl102{v r3Q3} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl106{v r3Q7} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl110{v r3Qb} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl134{v r3Qz} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl138{v r3QD} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl142{v r3QH} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl146{v r3QL} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl153{v r3QS} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl161{v r3R0} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl165{v r3R4} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl169{v r3R8} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl173{v r3Rc} [gid] True False +WARNING: file compiler/stgSyn/CoreToStg.lhs, line 269 + lvl177{v r3Rg} [gid] True False *** unexpected failure for integerConstantFolding(normal) }}} The warning is in `consistentCafInfo` source:compiler/stgSyn/CoreToStg.lhs and was was last touched by SPJ in [fdf86568], and originally introduced by simmonmar in 2e6d322e130a8c37807a14699bbcbf9eb08fc970. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8584: Pattern synonym type signatures
by GHC 17 Dec '14

17 Dec '14

#8584: Pattern synonym type signatures ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, the only way to specify a type signature for a pattern synonym is by adding type annotations to the right-hand side, like this: {{{ {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Single x = ([x] :: [Int]) }}} Bespoke syntax for adding type signatures for pattern synonyms would probably be useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8778: Typeable TypeNats
by GHC 15 Dec '14

15 Dec '14

#8778: Typeable TypeNats -------------------------------------------+------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 4385 | Test Case: | Blocking: -------------------------------------------+------------------------------- It would be useful (the case I have at hand is for some scenarios involving checking of physical dimensions) to be able to combine the Data.Dynamic story with the GHC.TypeLits story. A Typeable instance for every Nat is the sticking point. (I do not know if this is even theoretically possible.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #8240: Better error messages for type family constraints
by GHC 11 Dec '14

11 Dec '14

#8240: Better error messages for type family constraints ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- Consider this constraint {{{ F Int ~ Bool -- Arising (say) on line 5 F Int ~ Char -- Arising (say) on line 10 }}} At the moment we'll combine the two to {{{ F Int ~ Bool -- Arising on line 5 Bool ~ Char -- Arising on line 10 }}} The second of these errors is "insoluble" and is reported first. But it's totally misleading: nowhere in the program did we directly need `Int~Char`. Another variant of this came up in Trac #8227. There we get the constraint {{{ Scalar (V a) ~ t0 Scalar (V a) ~ t0 -> t0 }}} which leads to {{{ Scalar (V a) ~ t0 -> t0 t0 ~ t0 -> t0 -- Occurs check }}} which gives the confusing error {{{ T8227.hs:16:44: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t0 Expected type: Scalar (V (t0 -> t0)) Actual type: Scalar (V a) }}} I think the solution is * Do not combine two Wanteds {{{ [W] F tys ~ t1 [W] F tys ~ t2 }}} unless t1 and t2 are both touchable unification variables. * Instead (perhaps) generate a Derived constraint {{{ [D] t1 ~ t2 }}} to express the fact that t1 and t2 had better end up equal. * To do this the inert set would need to contain many `CTyFunEq` constraints with the same LHS. I'm not very sure about this, and no time now, so I'm just making this ticket to record the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1