January 2016 - ghc-tickets

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 29 Jan '16

29 Jan '16

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------- Reporter: skaller | Owner: juhp Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: None => invalid Comment: I'm closing this, since we don't ship RPMs anymore: commit 22690c9900068b121863dc359b8c7699b453e70d: {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Sun Jun 9 18:56:58 2013 +0100 Remove ghc.spec It doesn't look like it would work now, and doesn't really belong in the GHC tree anyway. }}} ydewit: please open a new ticket if you want to investigate relocatable installs on non-windows platforms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #989: Build GHC on Windows using Microsoft toolchain
by GHC 29 Jan '16

29 Jan '16

#989: Build GHC on Windows using Microsoft toolchain ------------------------------------+--------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+--------------------------- Changes (by thomie): * component: Build System => Compiler Comment: This reaches far beyond just the build system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/989#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11005: GHC's build system can't deal with ghc install path with multiple spaces in it
by GHC 29 Jan '16

29 Jan '16

#11005: GHC's build system can't deal with ghc install path with multiple spaces in it -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Build System | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Essentially, there are a bunch of places in the build system where we forget to quote paths, and so the spaces collapse into a single space and the paths fail. I fixed a few low hanging instances of this but I got hsc2hs to fail: {{{ "inplace/bin/hsc2hs" '--cc=/bin/gcc' '--ld=/bin/gcc' --cross-safe --cflag=-Wall --cflag=-fno-stack-protector --cflag=-Dx86_64_HOST_ARCH=1 --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 '--cflag=-fno- stack-protector' '--cflag=-Wall' '--cflag=-Icompiler/stage1/build/autogen' '--cflag=-Icompiler/.' '--cflag=-Icompiler/parser' '-- cflag=-Icompiler/utils' '--cflag=-Icompiler/stage1' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/process-1.2.3.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/directory-1.2.2.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/unix-2.7.1.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/time-1.5.0.1/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/bytestring-0.10.6.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/base-4.8.2.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/integer-gmp-1.0.0.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/include' '--cflag=-Werror=unused-but-set- variable' '--cflag=-Wno-error=inline' '--lflag=-L/home/hs01/ezyang/ghc- bootstrap/libraries/transformers/dist-boot/build' '-- lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/template-haskell/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/process-1.2.3.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/pretty-1.1.2.0' '--lflag=-L/home/hs01/ezyang /ghc-bootstrap/libraries/hpc/dist-boot/build' '--lflag=-L/home/hs01/ezyang /ghc-bootstrap/libraries/hoopl/dist-boot/build' '-- lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/ghc-boot/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/directory-1.2.2.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/unix-2.7.1.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/time-1.5.0.1' '--lflag=-L/home/hs01/ezyang/ghc- validate/bindisttest/install dir/lib/ghc-7.11.20151022/filepath-1.4.0.0' ' --lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/binary/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/containers-0.5.6.2' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/bytestring-0.10.6.0' '-- lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/deepseq-1.4.1.1' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/array-0.5.1.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/base-4.8.2.0' '--lflag=-L/home/hs01/ezyang/ghc- validate/bindisttest/install dir/lib/ghc-7.11.20151022/integer- gmp-1.0.0.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/ghc-prim-0.4.0.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/rts' '-- lflag=-lrt' '--lflag=-lutil' '--lflag=-ldl' '--lflag=-lpthread' '-- lflag=-lgmp' '--lflag=-lm' '--lflag=-lrt' '--lflag=-ldl' '--lflag=-lelf' ' --lflag=-ldw' --cflag=-Icompiler/stage1/build/autogen --cflag=-include --cflag=compiler/stage1/build/autogen/cabal_macros.h compiler/utils/Fingerprint.hsc -o compiler/stage1/build/Fingerprint.hs }}} Notice that there is only a single space in the `include` path passed to hsc2hs. I didn't feel like tracking down where we didn't quote enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10707: -fth-dec-file outputs invalid case clauses
by GHC 29 Jan '16

29 Jan '16

#10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10701 Differential Revisions: | -------------------------------------+------------------------------------- instance Data.Aeson.Types.Class.ToJSON Language.Haskell.TH.Syntax.Name where Data.Aeson.Types.Class.toJSON x = \ k_a94l v_a94m -> case k_a94l of { GHC.Base.Just "" -> GHC.Err.undefined GHC.Base.Nothing -> GHC.Err.undefined } (GHC.Base.Just "test") "test2" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11507: `GHC.Base.eqString`'s documentation is messed up
by GHC 28 Jan '16

28 Jan '16

#11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | 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: -------------------------------------+------------------------------------- Reads: {{{#!hs {-# RULES "eqString" (==) = eqString #-} -- eqString also has a BuiltInRule in PrelRules.lhs: -- eqString (unpackCString# (Lit s1)) (unpackCString# (Lit s2) = s1==s2 }}} The problem is that the string at `(unpackCString# (Lit s2) =` is unclosed (should be `(unpackCString# (Lit s2))`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11482: Turn -fdefer-typed-holes on by default
by GHC 28 Jan '16

28 Jan '16

#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | 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: #9497, #11481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they’re easy to detect during a production build.↩ That's terrible, they should be using typed holes! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does always show a warning (unless explicitly suppressed). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11506: uType_defer can defer too long
by GHC 28 Jan '16

28 Jan '16

#11506: uType_defer can defer too long -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Here is the test case: {{{ {-# LANGUAGE PolyKinds, ExistentialQuantification, ScopedTypeVariables, TypeFamilies, TypeInType #-} module Bug where import Data.Proxy import Data.Kind type family ProxyType where ProxyType = (Proxy :: Type -> Type) data T = forall a. MkT (ProxyType a) foo (MkT (_ :: Proxy a)) = const True (undefined :: a) }}} This should be accepted. But I get {{{ Bug.hs:13:53: error: • Expected a type, but ‘a’ has kind ‘k10’ • In an expression type signature: a In the second argument of ‘const’, namely ‘(undefined :: a)’ In the expression: const True (undefined :: a) }}} Why should it be accepted? GHC can infer that the existential `a` in `MkT` has kind `Type`. (Indeed this works.) Then, we should unify the pattern signature `Proxy k1 a1` with `ProxyType a2`; the latter expands to `Proxy Type a2` and we get `k1 := Type` and `a1 := a2`, allowing `undefined :: a` to be accepted. Why doesn't it work? When checking the pattern type signature in `foo`, GHC then checks if `ProxyType a2` is a subtype of `Proxy k1 a1`. This check is deferred because of the type family. In a short while, GHC needs to know that `a` has kind `Type` to make sure that `undefined :: a` is well-typed. At this point, it doesn't know that `a` has kind `Type` (because the unification was deferred), and so an error is issued. I'm not sure how to resolve this. This is indeed a consequence of `TypeInType`, but it seems more to do with solver engineering than the new `TypeInType` stuff. And there is an easy workaround: just add a kind signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11486: info tables are no longer aligned
by GHC 28 Jan '16

28 Jan '16

#11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Take a simple program like {{{ main = mapM_ print "Hello, world" }}} and build with `-O`. Versions of ghc as late as 7.11.20150806 generate assembly that includes {{{ ... _c3mn: movq $sat_s3m2_info,-16(%r12) movq %r14,(%r12) movq $block_c3mi_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info .text .align 8 .quad 1 .quad 32 block_c3mi_info: _c3mi: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast ... }}} Note the `.align 8` ensuring that the info table (and the code `_c3mi` itself) is 8-byte aligned. In 8.1.20160107 we instead get {{{ _c5gE: movq $sat_s5g9_info,-16(%r12) movq %r14,(%r12) movq $block_c5gz_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info _c5gF: movq $24,904(%r13) _c5gC: movl $Main.main2_closure,%ebx jmp *-8(%r13) .quad 1 .quad 32 block_c5gz_info: _c5gz: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast .size Main.main2_info, .-Main.main2_info }}} There is some minor rearrangement, but more importantly there is no longer any `.align 8` before `.quad 1`. That means the info table is not necessarily aligned, and indeed `c5gz_info` ended up at the address `40676f`. I'm guessing this is bad for performance, though I don't know how bad. I'm pretty sure this is due to 4a32bf925b8aba7885d9c745769fe84a10979a53 "Implement function-sections for Haskell code" though I haven't looked at that commit in detail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #5654: Profiling semantics bug
by GHC 27 Jan '16

27 Jan '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Commit that nomeata mentioned in comment:10 (Phab:D1821 actually): commit f42db1574935b088cfc13cca7c935990002651dc {{{ Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Sat Jan 23 13:12:10 2016 +0100 Remove unused IND_PERM it seems that this closure type has not been in use since 5d52d9, so all this is dead and untested code. This removes it. Some of the code might be useful for a counting indirection as described in #10613, so when implementing that, have a look at what this commit removes. Test Plan: validate on harbormaster Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1821 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11481: New GHCi command `:load!` doesn't defer typed holes
by GHC 27 Jan '16

27 Jan '16

#11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: -------------------------------------+------------------------------------- Test.hs: {{{#!hs f :: Int f = _ main = print f }}} {{{ $ ghc-8.0.1 --interactive GHCi, version 8.0.0.20160111: http://www.haskell.org/ghc/ :? for help Prelude> :load! Test.hs [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:2:5: error: • Found hole: _ :: Int • In the expression: _ In an equation for ‘f’: f = _ • Relevant bindings include f :: Int (bound at Test.hs:2:1) Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10