- ghc-tickets - Haskell.org

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 01 Feb '16

01 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > But what's odd is that it doesn't bomb out on us when the ASSERT is not there. That seems odd to me -- if the types get very large I'd expect the type checker to fail even in the absence of the ASSERT. I think I can explain this. The [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/… unwrapNewTypeStepper] is protected by a [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/… checkRecTc] which will cause an abort if the same newtype constructor is unwrapped 100 times. The difference I believe is due to laziness and sharing, it's easy to create an exponentially big type by repeated substitution into `(a, a)` and unless `a` is (deeply) forced at some point you can do it in sub-exponential time. So when `substTy` began to force it by computing the free variables for the sanity check the problem became visible. In other words the recursion check in `checkRecTc` didn't need to force the type to decide it was a loop, so it wasn't bothered by it growing exponentially (made possible by sharing and laziness) before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 01 Feb '16

01 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. If the reason that the ASSERT gets exponentially expensive is that the types get exponentially large, that's a good explanation. That indeed is a hard problem (see e.g. #9198). But what's odd is that it doesn't bomb out on us when the ASSERT is not there. That seems odd to me -- if the types get very large I'd expect the type checker to fail even in the absence of the ASSERT. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 31 Jan '16

31 Jan '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 11371 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to dig more, but I expect I might not know how to best fix this. In general how does the typechecker deal with types that can get exponential? The part of the code that generates such types is: {{{ newtype VoidBad a = VoidBad (VoidBad (a,a)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 30 Jan '16

30 Jan '16

#3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10656 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "93098974.png" added. [http://smartmiltoys.com/kidkraft-train-table/ http://smartmiltoys.com /kidkraft-train-table/] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11517: ghc -haddock fails to parse doc comments in closed type families
by GHC 30 Jan '16

30 Jan '16

#11517: ghc -haddock fails to parse doc comments in closed type families -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: Haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC with -haddock fails to parse the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Closed a where -- |This comment fails to parse Closed Int = Bool }}} {{{ ghc -haddock Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: parse error on input ‘-- |This comment fails to parse’ }}} (tested with 7.10.3 and an slightly out-of-date HEAD) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11082: Tweak workflow around overlong lines
by GHC 30 Jan '16

30 Jan '16

#11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.2 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: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/ghc-devs/2015-November/010373.html This thread] discussed potential changes to the way the GHC dev workflow deals with overlong lines. This ticket summarizes the discussion. '''Initial complaint:''' arc/Phab is too heavy-handed about overlong lines. Almost all patchers have to write a vacuous "explanation" for them, and the overlong line warnings clutter code reviews. '''Initial suggestion:''' After `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of {{{ Before your patch, 15 of the edited lines were over 80 characters. Now, a whopping 28 of them are. Can't you do better? Please? }}} '''Reactions:''' * +1 * Even the delta in overlong lines is bad, because perhaps a small refactor added to the length of an identifier. * We might just want to reject code with overlong lines. Then the problem would really go away. It favors one-time work over many-time maintenance burden. (Austin's point, +1 by Alexander Berntsen) * This would cause more work and would increase the barrier to contribution. And sometimes it's appropriate/more readable to have overlong lines. * 80 is too small. 120 (SPJ)? 132 (Ed Kmett)? * And a small limit discourages informative identifiers. * Just drop the column limit entirely. * Why 80? Because two 80-column buffers fit nicely side-by-side on small laptop screens. Three such columns fit nicely on monitors. Several (4 emails) echoed this point. Bottom line: no one expressed liking the status quo (though Simon M called it "not terrible"). If we're to choose a limit, a choice of 80 seemed to appease the plurality of respondents. Two respondents advocate enforcing the limit. I count four respondents rejecting hard enforcement. In my (surely biased) view, this means that we should implement my original proposal. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10310: MakingReleases outdated or build system problems
by GHC 30 Jan '16

30 Jan '16

#10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hey, I have some problems following https://ghc.haskell.org/trac/ghc/wiki/MakingReleases with HEAD. I'll collect them here, maybe we can update the Wiki page together, or fix the corresponding problems in the build system if they are problems. 1) `make sdist` fails with the problem that `ghc-tarballs` doesn't exist. I've heard that's only needed on Windows, and that some people seem to get it by cloning a submodule when they are on Windows. A `mkdir ghc-tarballs` fixed it. Maybe that directory should be created by the build system? 2) When I `make` in the unpacked sdist tarball, I get {{{ "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --ps -o utils/haddock/doc/haddock.ps "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --pdf -o utils/haddock/doc/haddock.pdf /bin/bash: : command not found /bin/bash: : command not found make[1]: *** [utils/haddock/doc/haddock.ps] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/doc/haddock.pdf] Error 127 }}} Looks like some program was set to the empty string here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

30 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 30 Jan '16

30 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 30 Jan '16

30 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