September 2016 - ghc-tickets

[GHC] #9184: Allow the use of Python 3 when building GHC
by GHC 01 Dec '16

01 Dec '16

#9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling
by GHC 01 Dec '16

01 Dec '16

#11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ⊥ Component: Template | Version: 7.11 Haskell | 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: -------------------------------------+------------------------------------- In a non cross-compiled stage 2 compiler, this coincides with what we do today, because the stage 1 implementation of GHC is the same as the stage 2 implementation. But in a cross-compiler, these are NOT the same: the cross-compiler's ghc library handles the package database in the target platform, whereas the compiler that built stage 2 (stage 1)'s ghc library handles the package database for the compiler's platform. So, the correct architecture for supporting compiler plugins is that GHC should use the package-database/interface infrastructure from the compiler which built it (stage 1) to handle loading. A few things to note: 1. There is not a backwards-compatibility problem, because we can assume that stage 1 and stage 2 are built from the same codebase. In particular, this does NOT mean that TH/plugins start working on a stage 1 compiler. You have to have bootstrapped from the same codebase. 2. Plugins (and even Template Haskell) have to be a bit more careful to take advantage of this. We cannot just assume that the package database for plugins is the same as the package database for compiling (revisiting #11244). Template Haskell is even trickier: we should NOT be allowed to use regular imports in splices; they have to go through `TH_ONLY` imports, c.f. #11377 3. Can we actually link against the old version of `ghc`? Yes we can! All we need is (1) for it to have been built with a different IPID, and (2) to use module renaming to rename the relevant modules to a different module name, so that we can import them without a conflict. Stepping back, there have been two approaches for dealing with the problem of Template Haskell/compiler plugins not reliably working: 1. Run the code in an external process run in the target code, or 2. Fix GHC to load code which is appropriately built for the bootstrap platform. While (1) offers a more uniform environment for developers, (2) is absolutely necessary in some situations when you need to load code in the same address space as GHC, e.g. as mentioned in https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html Thus, it seems worth pursuing both. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11377: Template Haskell only imports
by GHC 01 Dec '16

01 Dec '16

#11377: Template Haskell only imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Template | Version: 7.11 Haskell | 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: -------------------------------------+------------------------------------- This is the Template Haskell equivalent of #11244. It should be possible to use the plugin package database to make a Template Haskell only import; I suggest the syntax `import {-# TH_ONLY #-} Foo`. Such imports are only allowed to be used in splices, and cannot be quoted (they are not allowed to reside in the final code generated by the splice.) The reason a user may want to use such an import is that it means that they can declare that a library is necessary when compiling splices, but not necessary when actually linking against it. There are extra benefits. If a user is compiling the package with the splices with profiling, it ordinarily requires all imports to have been compiled with profiling. This would NOT be necessary for a `TH_ONLY` import, since we're only ever going to run the imported code in the (non- profiled) compiler, and not in the (profiled) executable.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11293: Compiler plugins don't work with profiling
by GHC 01 Dec '16

01 Dec '16

#11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 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: -------------------------------------+------------------------------------- Suppose I have a normally built compiler plugin, and I'd like to use it while building some profiled code. This doesn't work: (non-profiled) GHC searches for the profiled version of the plugin. This is wrong wrong wrong: plugin searches should be with respect to how GHC was compiled. (Test case: take the `plugins01` test and add `-prof` to it) Now that we have `-plugin-package`, it should be a simple matter to ensure that plugin lookups follow a different codepath, though I'm not sure how to figure out what GHC is built with; this should just be however TH does it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11974: `default` declaration doesn't allow higher-kinded types
by GHC 30 Nov '16

30 Nov '16

#11974: `default` declaration doesn't allow higher-kinded types -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Since we now have #10971, I would expect the following to work: {{{ {-# LANGUAGE ExtendedDefaultRules #-} module Bug where default (Maybe, []) }}} But it doesn't. Sadly, the default default list contains `[]`, but the user can never set this. Fix on the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10510: Testsuite driver does not run tests in parallel on Windows
by GHC 30 Nov '16

30 Nov '16

#10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `testsuite/driver/runtests.py` contains the following 3 lines: {{{ if windows: print("Warning: Ignoring request to use threads as running on Windows") config.use_threads = 0 }}} They were introduced in commit e9b3d6cc65c0b69bd4a50bfa7bc7e1d3536446a8: {{{ Author: Ian Lynagh <> Date: Wed Oct 28 17:54:21 2009 +0000 Don't use threads on Windows It seems to cause some sort of deadlock }}} I tried removing them (Windows 64 bit, using msys2), but then running validate doesn't get any further than: {{{ ... =====> Overlap3(normal) 1605 of 4525 [2, 7, 0] =====> Overlap4(normal) 1606 of 4525 [2, 7, 0] =====> Overlap5(normal) 1607 of 4525 [2, 7, 0] =====> Overlap6(normal) 1608 of 4525 [2, 7, 0] =====> Overlap7(normal) 1609 of 4525 [2, 7, 0] =====> Overlap9(normal) 1610 of 4525 [2, 7, 0] }}} It would be great if we could run the testsuite in parallel again, since running validate takes forever currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12587: InstanceSigs doesn't work with ambigous types
by GHC 30 Nov '16

30 Nov '16

#12587: InstanceSigs doesn't work with ambigous types -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Why this code: {{{#!hs {-# LANGUAGE ScopedTypeVariables, InstanceSigs, AllowAmbiguousTypes #-} module Bug where class Foo a class Bar a where bar :: forall b. (Foo b) => a instance Bar Int where bar :: forall b. (Foo b) => Int -- error here bar = undefined where x :: b x = undefined }}} is rejected with message: {{{ Error: * Could not deduce (Foo b0) from the context: Foo b bound by the type signature for: bar :: Foo b => Int at Bug.hs:11:12-35 The type variable `b0' is ambiguous * When checking that: forall b. Foo b => Int is more polymorphic than: forall b. Foo b => Int When checking that instance signature for `bar' is more general than its signature in the class Instance sig: forall b. Foo b => Int Class sig: forall b. Foo b => Int In the instance declaration for `Bar Int' }}} ? Where does `b0` type var come from? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults
by GHC 29 Nov '16

29 Nov '16

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64) 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #12554: Testsuite exibits large amount of framework failures
by GHC 29 Nov '16

29 Nov '16

#12554: Testsuite exibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried this on multiple computers and they all have the same issue. I get around 400 testsuite failures with the error: {{{ r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run') }}} What they all have in common is that they are all using the latest MSYS2 and tools: {{{ Tamar@Squid MINGW64 ~/ghc $ python3 --version Python 3.5.2 Tamar@Squid MINGW64 ~/ghc $ uname -a MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #11219: Implement fine-grained `-Werror=...` facility
by GHC 29 Nov '16

29 Nov '16

#11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- ...copied from Design/Warnings: Introduce variant of `-Werror` (c.f. GCC's `-Werror=*`) which allows to specify the individual warnings to be promoted to errors, e.g. - `-Wall -Werror=orphans` would only promote `-Worphans` warnings into errors - `-Wall -Werror -Wno-error=missing-methods` would promote all warnings //except// `-Wmissing-methods` into errors TODO: specify semantics a bit more exactly (the basic idea is to follow gcc/clang as much as sensible, and only deviate where it's necessary) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10