April 2015 - ghc-tickets

[GHC] #9626: Test command lines munged on Windows when running on msys Python
by GHC 09 Jun '15

09 Jun '15

#9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On Windows, the test runner works fine if run under Windows-native Python, but fails with the msys Python because of the heuristic transformations that msys applies to all binary invocations of non-msys binaries (such as timeout.exe) by msys binaries (such as python). This is relatively easy to sidestep by going through /usr/bin/cmd in msys which sidesteps the argument munging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9259: GHCi should list its available command line options
by GHC 08 Jun '15

08 Jun '15

#9259: GHCi should list its available command line options -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Keywords: | 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: -------------------------------------------+------------------------------- GHC can now list its command line options with `--show-options` (#7843). GHCi should be able to do the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8244: Removing the Cabal dependency
by GHC 06 Jun '15

06 Jun '15

#8244: Removing the Cabal dependency ------------------------------------+------------------------------------- Reporter: nh2 | 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: | ------------------------------------+------------------------------------- GHC depends on cabal, which is so far has been problematic many times, for many reasons. A few discussions include: * http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html * http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html GHC uses only a very small part of Cabal, in these files: {{{ ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs }}} plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html for details). It was proposed that either * the package format could be a plain specification without direct code dependencies * the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*). Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors
by GHC 04 Jun '15

04 Jun '15

#10178: hs-boot/hsig ambiguity empty data declaration or type with no constructors -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I write in a boot or signature file: {{{ data Foo }}} it is ambiguous whether or not this is a fully-specified empty data declaration, or a data type which has its constructors unspecified. This doesn't matter too much for hs-boot (since you can't use the data constructors in any case) but for signatures we might want to force a data type to be empty. Though I think this case should be rare. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8723: sdist should not have to build everything
by GHC 04 Jun '15

04 Jun '15

#8723: sdist should not have to build everything ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It would be nice if instead of {{{ $ perl boot $ ./configure $ make $ make sdist }}} it would suffice to run {{{ $ perl boot $ ./configure $ make sdist }}} and if that would not build more than necessary to generate the tarballs. It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on. I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-)) Remember to update MakingReleases and Building/StandardTargets if this is implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9507: ghc-pkg mode to query by package-key
by GHC 04 Jun '15

04 Jun '15

#9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Right now, ghc-pkg understands package names and IPIDs. It should support package keys too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10145: :info (->) should list its fixity
by GHC 04 Jun '15

04 Jun '15

#10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The GHC manual states: > * Function arrow is `infixr` with fixity 0. (This might change; I'm not sure what it should be.) Since this isn't the default `infixl 9`, it should be listed when you do `:info (->)`, but currently (at least in 7.8.3) isn't. (Inspired by [http://stackoverflow.com/questions/28916291/associativity- of/28916978#28916978 this Stackoverflow question].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10330: Better Template Haskell error message locations
by GHC 04 Jun '15

04 Jun '15

#10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this TH splice {{{ f x = $( [| let g x = (True && 'x', x) in g True |] ) }}} or more generally {{{ f x = $( g [| x |]) }}} Two problems 1. If there is a type error in the spliced-in code, there is no record of the splice in the error message: {{{ TH.hs:5:10: Couldn't match expected type ‘Bool’ with actual type ‘Char’ In the second argument of ‘(&&)’, namely ‘'x'’ In the expression: (True && 'x') In the expression: ((True && 'x'), x_a2qf) }}} I'd like to see {{{ TH.hs:5:10: Couldn't match expected type ‘Bool’ with actual type ‘Char’ In the second argument of ‘(&&)’, namely ‘'x'’ In the expression: (True && 'x') In the splice: $( [| let g x = ... in g True |] ) <------- NB }}} 2. (Less important, and harder to fix.) The error location (column 10) is that of the splice (column 10), not where the reported error really is (column 31). Fixing this would mean round-tripping source location info through TH syntax. Moreover, since the constructed code may be combined from quoted snippets spread over some TH libraries, it's far from clear that the location info would help. Thoughts about fixing (1). This can only arise for untyped splices. (For typed splices we can't get type errors in spliced code.) So the renamer should produce a syntax tree with a variant of `HsPar` saying "here is where I spliced in an expression". Same think for patterns and types; for declarations it would be a bit more fiddly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules
by GHC 03 Jun '15

03 Jun '15

#10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When you have an instance defined in a module that's part of a recursive module loop, when should modules outside the loop see it? Right now, GHC behaves differently depending on whether it's in batch or in single-shot compilation mode. Which one is correct? Dunno! Here's the example (code at the bottom). The gist is that you have two modules A and B that define data types T and U, respectively, which depend on each other, so A and B are recursive modules and we need a boot file -- say, for A. Now suppose we define an instance Eq T in the implementation of A but not in the boot file. B imports the boot file, so it doesn't know about this instance. And then I have some third module, Main, outside the loop, which imports only B. And now the central question: ''Does Main know about the Eq T defined in A?'' We can test how GHC answers this question by defining an (orphan) instance for Eq T in Main. In batch compilation mode, Main is rejected for defining a duplicate instance. In single-shot compilation mode, however, Main is accepted and any equality test in Main uses the locally defined instance; i.e., B doesn't know about A's Eq T and so neither does Main. So which is correct? If you ask me, the latter semantics is correct, but I can see why the former might be argued as well (e.g., according to the fixed-point semantics of import/export described in (1)). In any case, the semantics between the two compilation modes should probably agree, right? {{{#!hs -- A.hs-boot module A where data T -- a mutually recursive data type, along with B.U t :: T -- some value to test for Eq in Main -- B.hs module B(module A, module B) where -- export A.{T,t} since Main doesn't import A import {-# SOURCE #-} A -- mutually recursive data type across modules data U = U | UT T -- A.hs module A where import B -- mutually recursive data type across modules data T = T | TU U -- the true instance instance Eq T where _ == _ = True -- some value to test Eq instance in Main t :: T t = T -- Main.hs module Main where import B -- no import of A -- an orphan instance for Eq T. -- okay in one-shot mode; not okay in batch (--make) mode instance Eq T where _ == _ = False -- in one-shot mode, this prints False main = putStrLn $ show $ t == t }}} Commands and output for batch mode: {{{ $ ghc --make Main [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) A.hs:8:10: Duplicate instance declarations: instance Eq T -- Defined at A.hs:8:10 instance Eq T -- Defined at Main.hs:7:10 }}} Commands and output for single-shot mode: {{{ $ ghc -c A.hs-boot $ ghc -c B.hs $ ghc -c A.hs $ ghc -c Main.hs $ ghc A.o B.o Main.o -o main $ ./main False }}} Tested on GHC 7.6.3, 7.8.3, and 7.10.1. (1) ''A Formal Specification for the Haskell 98 Module System''. Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. Haskell '02. http://web.cecs.pdx.edu/~mpj/pubs/hsmods.pdf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9506: Name libraries (dll/so) separately from linker symbols
by GHC 03 Jun '15

03 Jun '15

#9506: Name libraries (dll/so) separately from linker symbols -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Tracking ticket so I don't forget. Based on feedback on `#ghc`, it sounds like it would be helpful if library names on the file system only had their full package name, e.g. `libHScontainers_HASH.so` as opposed to the abbreviated package name. Additionally, it seems less necessary to provide the abbreviated package name in linker symbols, since the modules often give a pretty good clue (and the package key can be looked up.) So let's do this, and make things better for users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1