February 2014 - ghc-tickets

[GHC] #8730: Invalid Unicode Codepoints in Char
by GHC 16 Nov '14

16 Nov '14

#8730: Invalid Unicode Codepoints in Char ------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: unicode | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac
by GHC 16 Nov '14

16 Nov '14

#8756: Test case concurrent/should_run/T5611 fails on Mac ------------------------------------+------------------------------------- Reporter: goldfire | 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: | ------------------------------------+------------------------------------- On a fresh check out, test case concurrent/should_run/T5611 fails: {{{ Actual stderr output differs from expected: --- ./T5611.stderr 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stderr 2014-02-08 22:00:06.000000000 -0500 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) Actual stdout output differs from expected: --- ./T5611.stdout 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stdout 2014-02-08 22:00:06.000000000 -0500 @@ -1,2 +1,3 @@ child: Sleeping +child: Done waiting parent: Done throwing exception *** unexpected failure for T5611(normal) }}} I'm on Mac OS 10.8.5 with Xcode 4.6.1 (4H512). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8798: Missing symbols with -fprof-auto-calls
by GHC 16 Nov '14

16 Nov '14

#8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | 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: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 14 Nov '14

14 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8750: Invalid identifier generated with Template Haskell not rejected
by GHC 13 Nov '14

13 Nov '14

#8750: Invalid identifier generated with Template Haskell not rejected --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I wrote Template Haskell code that generates this declaration: {{{ data (:+Sym1) (a:: Nat) (b :: TyFun Nat Nat) }}} `(:+Sym1)` is not a valid identifier and this declaration fails when I simply put it in a source file and try to compile it. However I get no errors when this definition is generated from Template Haskell. Not sure if this is intended behaviour or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | 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: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8672: :browse and roles on typefamilies
by GHC 10 Nov '14

10 Nov '14

#8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8699: Multiple test faliures on 32-bit Linux systems.
by GHC 07 Nov '14

07 Nov '14

#8699: Multiple test faliures on 32-bit Linux systems. ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I ran validate with HEAD (e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19) on 3 different 32-bit Linux boxes and I'm seeing different failures on each one. I was advised on IRC to create a ticket with all the failures. The first and third box are using the binary of 7.6.3 provided on the GHC site. I had to link libgmp.so.3 to libgmp.so.10 on both of these in order to get it to install properly. Please ask about any info that I have not provided below! First box: {{{Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.0 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.0, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 16 Oct 14 04:24 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 lrwxrwxrwx 1 root root 12 May 31 2013 /usr/lib/libgmp.so.3 -> libgmp.so.10 }}} The full log is at [1]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.base" OVERALL SUMMARY for test run started at Sun Jan 26 03:26:36 2014 GMT 0:19:58 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3458 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} As discussed on the mailing list, the Haddock numbers still need tweaking even after Austin updated them the other day. T1969 failure seems to come and go. ---- Second box: {{{Linux yuuki 3.11.4-gentoo #1 SMP Tue Oct 8 00:19:37 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} I installed the bootstrapping compiler on this box from Gentoo's package manager so I'm not sure how gmp is linked here. I can retry by boostrapping from binary and linking libgmp.3 to libgmp.10 (like the other boxes did) for consistency. The version of this complier is 7.6.3-r1. The full log is at [2]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.compiler T7859" OVERALL SUMMARY for test run started at Sun Jan 26 03:34:47 2014 GMT 0:12:04 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3453 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} A different Haddock perf failure, T1969 seems to have failed again and a totally new failure, T7859. ---- Third box: {{{Linux lenalee 3.11.4-gentoo #1 SMP Mon Oct 7 19:19:00 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 9 Jan 26 02:42 /usr/lib/libgmp.so.3 -> libgmp.so lrwxrwxrwx 1 root root 16 Nov 20 11:54 /usr/lib/libgmp.so -> libgmp.so.10.1.3 }}} The full log is at [3]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="hsc2hs004 T3837 haddock.compiler haddock.base T3307 environment001 T1969 gadt23 Capi_Ctype_001 Capi_Ctype_002" OVERALL SUMMARY for test run started at Sun Jan 26 03:28:47 2014 GMT 0:10:37 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3446 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ../../libraries/base/tests/IO T3307 [bad stderr] (normal) ../../libraries/base/tests/IO environment001 [bad stderr] (normal) ffi/should_run Capi_Ctype_001 [bad stderr] (normal) ffi/should_run Capi_Ctype_002 [bad stderr] (normal) gadt gadt23 [bad stderr] (normal) hsc2hs T3837 [bad stderr] (normal) hsc2hs hsc2hs004 [bad stderr] (normal) perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} Whole plethora of failures! Haddock numbers again and a bunch of other stuff. Considering how close 7.8 is, I think these should be looked at (especially that last set doesn't look too good). I notice that over 2000 more tests were skipped on the first box (this is my day-to-day use computer). How are the tests to be skipped determined? [1]: http://fuuzetsu.co.uk/misc/validate-misaki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [2]: http://fuuzetsu.co.uk/misc/validate-yuuki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [3]: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8828: allow fully applied type families in instance heads
by GHC 07 Nov '14

07 Nov '14

#8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ‛Show (TX Int)’ }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8812: Make *_stub.c files available again
by GHC 07 Nov '14

07 Nov '14

#8812: Make *_stub.c files available again ------------------------------------+------------------------------------- Reporter: ralphb | 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: | ------------------------------------+------------------------------------- In our project we would like to link Haskell functions into C++ code. In principle this works fine using FFI. An additional constraint, however, is that we need to generate and link the object files ourselves. Alas, ghc no longer keeps the *_stub.c files around. (And fishing for files in /tmp is not a viable solution.) I would like to propose an additional command line switch to keep *_stub.c files, as previous compiler versions did by default. (Note that there is an older, similar request #7463, but our use case is much broader than that and not limited to unregistered compilation.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1