February 2014 - ghc-tickets

[GHC] #8447: A combination of type-level comparison and subtraction does not work for 0
by GHC 18 Nov '14

18 Nov '14

#8447: A combination of type-level comparison and subtraction does not work for 0 -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following function on type level naturals {{{ Diff x y = If (x <=? y) (y-x) (x-y) }}} does not work when either x or y is 0. https://github.com/nushio3/practice/blob/ea8a1716b1d6221ce32d77432b6de3f38e… /type-nats/int-bug.hs I've tested this code on ghc 7.7.20130926 since I couldn't build the really latest ghc. I'm sorry if it is already fixed on the ghc head. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8442: Cabal-install internal error with any use
by GHC 18 Nov '14

18 Nov '14

#8442: Cabal-install internal error with any use ----------------------------------+--------------------------------- Reporter: senk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Any attempt to use cabal-install fails with an internal error. Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling. {{{ cabal install hakyll cabal-install: internal error: evacuate(static): strange closure type -385875968 (GHC version 7.6.3 for x86_64_portbld_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory
by GHC 18 Nov '14

18 Nov '14

#8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory ------------------------------------+------------------------------------- Reporter: ygramoel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 trying to reproduce bug #8464 with the newest ghc; not available in my repositories, so I am trying to install it manually. With a freshly downloaded and unpacked ghc-7.6.3-x86_64-unknown- linux.tar.bz2, and after cleanly installing libgmp.3 (from source of gmp-4.3.1) johan@morla:~/work/ghc-7.6.3\> ./configure checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory johan@morla:~/work/ghc-7.6.3\> pwd -P /home/johan/work/ghc-7.6.3 johan@morla:~/work/ghc-7.6.3\> whereis libgmp libgmp: /usr/local/lib/libgmp.la /usr/local/lib/libgmp.a /usr/local/lib/libgmp.so johan@morla:~/work/ghc-7.6.3\> ls -l /usr/local/lib/libgmp* -rw-r--r-- 1 root root 1017334 Oct 20 20:56 /usr/local/lib/libgmp.a -rwxr-xr-x 1 root root 785 Oct 20 20:56 /usr/local/lib/libgmp.la lrwxrwxrwx 1 root root 15 Oct 20 20:56 /usr/local/lib/libgmp.so -> libgmp.so.3.5.0 lrwxrwxrwx 1 root root 15 Oct 20 20:56 /usr/local/lib/libgmp.so.3 -> libgmp.so.3.5.0 -rwxr-xr-x 1 root root 403890 Oct 20 20:56 /usr/local/lib/libgmp.so.3.5.0 johan@morla:~/work/ghc-7.6.3\> -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8465> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8477: Allow inferring ambiguous types
by GHC 18 Nov '14

18 Nov '14

#8477: Allow inferring ambiguous types ------------------------------------+------------------------------------- Reporter: aavogt | 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: 8390 | ------------------------------------+------------------------------------- Previous versions of ghc could infer types that are potentially ambiguous. This allowed things like http://okmij.org/ftp/Haskell/TypeLambdaVal.hs or assigning keyword args functions to variables http://code.haskell.org/~aavogt/HList/docs/HList/Data-HList-Keyword.html. Presently (7.6 and 7.7), you need to write a type signature yourself to allow such definitions, which in these situations doubles the amount of code to write. For the keyword case, the workaround is to use the kw function to apply the keyword function instead of ordinary function application. More related discussion http://www.haskell.org/pipermail/glasgow-haskell- users/2013-October/024404.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table`
by GHC 18 Nov '14

18 Nov '14

#8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` ----------------------------------+--------------------------------------- Reporter: jloos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm not sure if and how far the ghc-7.6.3 support for OS X is planned, but I hit a (possible) linker error with 7.6.3. I installed a homebrew gcc-4.8 and changed the ghc config to use it. I tried to compile the [http://hackage.haskell.org/package/bindings-GLFW bindings-GLFW] package, which was successful, and run `cabal test` on it, which fails with following error: {{{ final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} After some research I discovered that this symbol (surely just the first which fails) is part of the Objective-C Runtime. The /usr/lib/libobjc.dylib exports this symbol. In desperation I think I nearly reached the google quota with my research, further steps I tried: Explicitly link the libobjc lib {{{ ghci -lobjc dist/build/HSbindings-GLFW-3.0.3.o -framework Foundation -framework Cocoa -framework IOKit }}} With the same result as above: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/HSbindings-GLFW-3.0.3.o ... done Loading object (dynamic) /usr/lib/libobjc.dylib ... done Loading object (framework) IOKit ... done Loading object (framework) Cocoa ... done Loading object (framework) Foundation ... done final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} I found a [https://github.com/mxcl/homebrew/issues/23687 homebrew issue] related to gcc and the Apple switch from libstdc++to libc++ in 10.9 and i tried to force linking with explicit `-stdlib=libstdc++` in the cabal file (ld-options). But i guess this issue isn't related to the `__objc_***` problem, just tried it in desperation. Last week I managed to build ghc HEAD with clang bootstrapped with 7.4.6: the new linker mechanic seems to resolves this problem in a way (sadly some other packages aren't jet compatible with 7.8) So I'm not sure if this report is okay, if not, pardon me :) I'm aware of the problems with the current ghc-7.6.3 and the the changes OS X 10.9 brings with it (according to reddit/haskell cafe). The current suggestions is to not use the XCode-5.0.1/clang together with ghc-7.6.3. So I tried gcc from homebrew. I know that 7.8 will bring better linker capabilities, maybe there are just some flags to fix this specific problem with 7.6.3...? I didn't find it. So I thought it's better to report it. If further informations are required, I will try to provide them as fast as possible but I will have to downgrade to 10.8 tomorrow around 6 a.m. UTC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6
by GHC 18 Nov '14

18 Nov '14

#8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 ----------------------------------+------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- A couple of HP / GHC releases later this bug still seems to exist: http://ghc.haskell.org/trac/ghc/ticket/6138 32bit works fine, 64bit GHCi crashes frequently on startup, even with XCode 4.1 installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread
by GHC 18 Nov '14

18 Nov '14

#8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: | ------------------------------------+------------------------------------- It would be useful to be able to retrieve the label set by the labelThread function. For instance, a logging / tracing system could output a human readable string for the thread the trace originated from instead of just the thread ID. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES`
by GHC 18 Nov '14

18 Nov '14

#8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- In order to save contributor’s time, and in order to run the test suite faster, I suggest to not builds haddock and its dependencies (xhtml, anything else?) if `HADDOCK_DOCS=YES` is specified. The change is rather simple: {{{ diff --git a/ghc.mk b/ghc.mk index dd91a82..b0f93a0 100644 --- a/ghc.mk +++ b/ghc.mk @@ -437,7 +437,9 @@ REGULAR_INSTALL_PACKAGES += compiler endif REGULAR_INSTALL_PACKAGES += $(addprefix libraries/,$(PACKAGES_STAGE2)) +ifeq "$(HADDOCK_DOCS)" "YES" PACKAGES_STAGE1 += xhtml +endif ifeq "$(Windows_Target)" "NO" ifneq "$(TargetOS_CPP)" "ios" PACKAGES_STAGE1 += terminfo @@ -652,8 +654,10 @@ BUILD_DIRS += libraries/integer-gmp/gmp BUILD_DIRS += libraries/integer-gmp/mkGmpDerivedConstants endif +ifeq "$(HADDOCK_DOCS)" "YES" BUILD_DIRS += utils/haddock BUILD_DIRS += utils/haddock/doc +endif BUILD_DIRS += compiler BUILD_DIRS += utils/hsc2hs BUILD_DIRS += utils/ghc-pkg }}} and it does not affect validate runs, as validate has `HADDOCK_DOCS` set to `YES`. If this is introduced, I suggest to annotate these two with a tag in packages, so that one can run `./sync-all get --no-haddock`, similar to `--no-dph`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8544: Auto-Reference ticket-related branches in tickets
by GHC 18 Nov '14

18 Nov '14

#8544: Auto-Reference ticket-related branches in tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: | ------------------------------------+------------------------------------- This has two possible implementations (and both are useful and can complement each other): * Add a new field to the description „Related branch“. If for ticket #1234 there is a branch matching `T1234` (usually something like `wip/T1234`), link it from there. * When such a branch is created or deleted, post a message to the ticket. This way subscribers know about a possible ongoing implementation, and can review it. These should link somewhere I believe `https://ghc.haskell.org/trac/ghc/log/ghc?rev=<branchname>` is the most useful link. If the link is part of the „branch created“ message, it will become dangling after the branch is closed (presumably because the feature was merged; then the actually commits, if they reference the bug, will be auto-linked). I don’t think this is a problem. But if that is a problem, only put the link in the “Related branches” field, and clear it when the branch is deleted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing
by GHC 17 Nov '14

17 Nov '14

#8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Package system | 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: | ------------------------------------+------------------------------------- Here's a reduced test case: == cpp.hs == {{{ #!haskell {-# LANGUAGE CPP #-} #include "Typeable.h" main = return () }}} == command line == {{{ $ ghc-stage2 -c -package base cpp.hs In file included from cpp.hs:4:0: /home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2: warning: #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 [-Wcpp] #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 ^ compilation IS NOT required $ ghc-stage2 -c -package base -package containers cpp.hs compilation IS NOT required $ ghc-stage2 -c -package containers -package base cpp.hs }}} Notice that if I pass `-package containers` to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the `-package` directives. This behavior is intuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base. Does this sound okay? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2