December 2014 - ghc-tickets

[GHC] #9905: ghc-7.8.x command line error
by GHC 24 Dec '14

24 Dec '14

#9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `$ghc -e "import Data.List" -e "print 9"` will not output 9 but `ghc -e "print 9"` works normally. However, both commands work on ghc-7.6.x. Regards! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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

Re: [GHC] #3064: Very long compile times with type functions
by GHC 23 Dec '14

23 Dec '14

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time performance bug | Test Case: | perf/compiler/T3064 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: 7.6.1 => 7.12.1 Comment: From the second-to-last bullet point in Simon's commit message, it looks like this is a breaking change and should not be merged into 7.10 since RC1 is already out. I have to say the breakage is a little disappointing here. Here is the real-life example from the Note: {{{ class Ord r => UserOfRegs r a where ... (i1) instance UserOfRegs r a => UserOfRegs r (Maybe a) where ... (i2) instance (Ord r, UserOfRegs r CmmReg) => UserOfRegs r CmmExpr where ... }}} Note the `Ord r` constraint in `(i2)`, which is newly-required by this change. What's disappointing here is that `Ord r` is "obviously" derivable from `UserOfRegs r CmmReg`! While I understand the reasoning in the Note (that `UserOfRegs r CmmReg` is not strictly smaller than the instance head, and therefore looking in its superclasses might, in perverse but realistic scenarios, might cause the superclass dictionary to loop), it's far from obvious from a user standpoint. Is it possible to alert the user to this problem in an error message? It seems, from the diff, that this is not yet done. And, should this perhaps be the first 7.12 release note? As it's a breaking change, I do think it should be called out in the user manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3064: Very long compile times with type functions
by GHC 23 Dec '14

23 Dec '14

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.1 Component: Compiler | Version: 6.10.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time performance bug | Test Case: | perf/compiler/T3064 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): should this be merged into the 7.10 branch or remilestoned for 7.12 only? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3064: Very long compile times with type functions
by GHC 23 Dec '14

23 Dec '14

#3064: Very long compile times with type functions -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: low | closed Component: Compiler (Type checker) | Milestone: 7.6.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 6.10.1 Type of failure: Compile-time performance bug | Keywords: Test Case: perf/compiler/T3064 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"a6f0f5ab45b2643b561e0a0a54a4f14745ab2152/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6f0f5ab45b2643b561e0a0a54a4f14745ab2152" Eliminate so-called "silent superclass parameters" The purpose of silent superclass parameters was to solve the awkward problem of superclass dictinaries being bound to bottom. See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls Although the silent-superclass idea worked, * It had non-local consequences, and had effects even in Haddock, where we had to discard silent parameters before displaying instance declarations * It had unexpected peformance costs, shown up by Trac #3064 and its test case. In monad-transformer code, when constructing a Monad dictionary you had to pass an Applicative dictionary; and to construct that you neede a Functor dictionary. Yet these extra dictionaries were often never used. (All this got much worse when we added Applicative as a superclass of Monad.) Test T3064 compiled *far* faster after silent superclasses were eliminated. * It introduced new bugs. For example SilentParametersOverlapping, T5051, and T7862, all failed to compile because of instance overlap directly because of the silent-superclass trick. So this patch takes a new approach, which I worked out with Dimitrios in the closing hours before Christmas. It is described in detail in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls. Seems to work great! Quite a bit of knock-on effect * The main implementation work is in tcSuperClasses in TcInstDcls Everything else is fall-out * IdInfo.DFunId no longer needs its n-silent argument * Ditto IDFunId in IfaceSyn * Hence interface file format changes * Now that DFunIds do not have silent superclass parameters, printing out instance declarations is simpler. There is tiny knock-on effect in Haddock, so that submodule is updated * I realised that when computing the "size of a dictionary type" in TcValidity.sizePred, we should be rather conservative about type functions, which can arbitrarily increase the size of a type. Hence the new datatype TypeSize, which has a TSBig constructor for "arbitrarily big". * instDFunType moves from TcSMonad to Inst * Interestingly, CmmNode and CmmExpr both now need a non-silent (Ord r) in a couple of instance declarations. These were previously silent but must now be explicit. * Quite a bit of wibbling in error messages }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
by GHC 23 Dec '14

23 Dec '14

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 6.8.2 Libraries | Keywords: hsetbuffering Resolution: | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@…, core-libraries-committee@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2189#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9876: mkdir errors when running `make sdist`
by GHC 23 Dec '14

23 Dec '14

#9876: mkdir errors when running `make sdist` -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hi. Newcomer here. I was taking a look at #9095 and I get the following errors when running `make sdist`. {{{ "rm" -f sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 mkdir sdistprep mkdir: cannot create directory ‘sdistprep’: File exists make[1]: [sdist-windows-tarballs-prep] Error 1 (ignored) mkdir sdistprep/windows-tarballs mkdir sdistprep/windows-tarballs/ghc-7.9.20141208 mkdir sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs cd sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs && lndir /home/joe/src/ghc/ghc-tarballs "rm" -rf sdistprep/windows-tarballs/ghc-7.9.20141208/ghc-tarballs/.git cd sdistprep/windows-tarballs && "/bin/tar" chf - ghc-7.9.20141208 2> windows_extra_src_ghc_log | bzip2 -c > /home/joe/src/ghc/sdistprep/ghc-7.9.20141208-windows-extra-src.tar.bz2 "rm" -rf sdistprep/testsuite-ghc "rm" -f sdistprep/ghc-7.9.20141208-testsuite.tar.bz2 mkdir sdistprep mkdir: cannot create directory ‘sdistprep’: File exists make[1]: [sdist-testsuite-prep] Error 1 (ignored) mkdir sdistprep/testsuite-ghc mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208 mkdir sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite cd sdistprep/testsuite-ghc/ghc-7.9.20141208/testsuite && lndir /home/joe/src/ghc/testsuite /home/joe/src/ghc/testsuite: No such file or directory make[1]: *** [sdist-testsuite-prep] Error 1 make: *** [sdist] Error 2 }}} Generally when using 'mkdir' in a Makefile I've found it best to always use 'mkdir -p' just like you should how you should always use 'rm -f'. It's a simple fix. I'm submitting a patch for it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9879: Panic with partial type signatures
by GHC 23 Dec '14

23 Dec '14

#9879: Panic with partial type signatures -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Attempting to check kind of type hole `_` in GHCi or putting it in a TH quotation causes a panic `rnHsTyKi HsWildcardTy`: {{{ :kind _ let x = [t|_|] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9744: Make program name and project version configurable
by GHC 23 Dec '14

23 Dec '14

#9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- GHC uses `cProjectVersion` in a few places and `ghc` is hardcoded as the program name. This is used for example for determining the location of the user package database (`getAppUserDataDirectory "ghc"`) and the names of dynamic libraries. I've been working around this for GHCJS, but it requires copying quite a bit of code. I have a patch that adds the program name and version to `Settings` that I'll submit once I've tested GHCJS with HEAD. My patch just allows these settings to be changed by GHC API clients. However, we could also make GHC itself read its own values from the `settings` file. This way we could add a version tag to a GHC installation without recompiling, keeping its packages and package databases separate from existing ones. Let me know if there's any interest in this and I'll add it to the patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook
by GHC 23 Dec '14

23 Dec '14

#9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: GHC API | 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: -------------------------------------+------------------------------------- GHCJS has to jump through hoops to make annotations work and to get the necessary information for linking a TH splice. The main reason is that `hscCompileCoreExprHook` does not expose the `TcM` environment. Easiest fix would be to add {{{#!hs hscCompileCoreExprTcMHook :: HscEnv -> SrcSpan -> CoreExpr -> TcM HValue }}} to `Hooks`, but it'd be better to hook `runMeta` instead. Unfortunately `runMeta` is polymorphic, so it could be more tricky. I'm going to see if I can hook `runMeta` in a reasonable way, and if I run out of time for 7.10.1, send a patch with `hscCompileCoreExprTcMHook` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2