December 2015 - ghc-tickets

[GHC] #11231: GHC's configure script does not honour CC env var
by GHC 04 Apr '16

04 Apr '16

#11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- `./configure --help` tells us that: {{{ ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Report bugs to <glasgow-haskell-bugs(a)haskell.org>. }}} However, neither - `CC=clang-3.8 ./configure`, nor - `./configure CC=clang-3.8` has any effect. `./configure` keeps using the `/usr/bin/gcc` in `$PATH`. The only invocation that has the desired effect is - `./configure --with-gcc=clang-3.8` However, this is utterly surprising and confusing to experienced developers who are used to Autoconf `./configure` scripts adhering to the conventions regarding `CC`, and contradicts the `--help` message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10970: Built in MIN_VERSION macro support
by GHC 04 Apr '16

04 Apr '16

#10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Pursuant to https://mail.haskell.org/pipermail/ghc- devs/2015-September/010015.html Recapped here: when preprocessing Haskell source code, we generate a temporary stub header file which defines a number of MIN_VERSION macros, ala what Cabal generates today. Specifically, for every explicitly specified package dependency (via a `-package` or `-package-id` argument), we generate a `MIN_VERSION_pkgname` macro which tests for the version recorded for the package database. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10436: Excessive numbers of packages loaded for TH
by GHC 31 Mar '16

31 Mar '16

#10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases: {{{ ghc --make Blah.hs }}} vs {{{ ghc --make Blah.hs -package foo }}} In the first case, ghc will work out for itself which packages it needs to load to run the TH code in `Blah.hs` while in the second case, ghc will unconditionally load package `foo` in addition to anything else. Why is this a problem? Consider a real example (reported on IRC): {{{ ghc --make Main.hs [1 of 4] Compiling Uplink ( Uplink.hs, Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [3 of 4] Compiling Joystick ( Joystick.hs, Joystick.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... }}} This just loads `base` and its deps. Great, it works. Now the exact same `Main.hs` built by cabal (which of course uses `-package-id` flags): {{{ cabal build Building jpl-0.1.0.0... Preprocessing executable 'jpl' for jpl-0.1.0.0... [1 of 4] Compiling Uplink ( Uplink.hs, dist\build\jpl\jpl- tmp\Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, dist\build\jpl\jpl- tmp\FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package SHA-1.6.4.2 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. }}} ... snip a further 80, '''yes 80 packages''' ... {{{ Loading package linear-1.18.0.1 ... linking ... done. Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0' ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup }}} ... snip more boring details of the linker errors ... So yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place. So the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider `-package` flags to be instructions to load these packages for running TH code. As a bonus it'll be quicker and our build output shorter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8731: long compilation time for module with large data type and partial record selectors
by GHC 30 Mar '16

30 Mar '16

#8731: long compilation time for module with large data type and partial record selectors -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc1 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times. This seems to related to how GHC handles a many constructor data type with overlapping field names. the time is nearly the same for building a static module with O1 and O2 {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O2 1 ↵ [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total }}} {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O1 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total }}} heck even with -O0 its slow (though not terrible) {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O0 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total }}} Seems like there might something wrong in how we handle data types like this, the complexity need not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10853: Refine addTopDecls
by GHC 28 Mar '16

28 Mar '16

#10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`. }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10338: GHC Forgets Constraints
by GHC 26 Mar '16

26 Mar '16

#10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is possibly fixed by #10195, but I don't have a convenient means of testing it. At any rate, this testcase is considerably simpler than the one in #10195. {{{#!hs {-# LANGUAGE TypeFamilies, FlexibleContexts, GADTs, MultiParamTypeClasses #-} type family F r class (Functor t) => T t r where fromScalar :: r -> t r data Foo t r where Foo :: t (F r) -> Foo t r Scalar :: r -> Foo t r toF :: r -> F r toF = undefined convert :: (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} This code compiles with GHC 7.8.4. When I add a generic instance for `T` (which requires `FlexibleInstances`): `instance (Functor t, Num r) => T t r` GHC complains: {{{#!hs Could not deduce (Num (F r)) arising from a use of ‘fromScalar’ from the context (T t (F r)) bound by the type signature for convert :: (T t (F r)) => Foo t r -> Foo t r at Main.hs:(17,12)-(18,23) In the expression: fromScalar In an equation for ‘fromScalar'’: fromScalar' = fromScalar In the expression: let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} Of course the problem can be fixed by adding a type signature to `fromScalar` and adding `ScopedTypeVariables`: {{{#!hs convert :: forall t r . (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar :: F r -> t (F r) in Foo $ fromScalar' $ toF c }}} Like #10195, this is triggered when a generic instance is in scope. The (main) problem of course is that GHC tries to match the generic instance instead of using the `T (F r)` constraint supplied by `convert`. A secondary issue is that I think the example should have the same behavior pre- and post-instance, i.e either both should compile or both should not compile. I'm not sure if a monomorphism restriction is actually being triggered here or if that's just a red herring. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken
by GHC 24 Mar '16

24 Mar '16

#11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 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: -------------------------------------+------------------------------------- When I say {{{ data family Fuggle x y [d| data instance Fuggle Int (Maybe (a,b)) where MkFuggle :: Fuggle Int (Maybe Bool) |] }}} I get (with `-ddump-splices`) {{{ [d| data instance Fuggle Int (Maybe (a_ajz6, b_ajz7)) where MkFuggle_ajz5 :: Fuggle Int (Maybe Bool) |] ======> data instance Fuggle Int (Maybe (a_ajAf, b_ajAg)) = (b_ajAg ~ Maybe Bool, a_ajAf ~ Int) => MkFuggle_ajAe }}} But that's not at all what I said! Admittedly, what I said was garbage, but it should fail outright. Is this addressed by Phab:D1465? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c)
by GHC 24 Mar '16

24 Mar '16

#9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- After talking with Simon & Simon today, we discussed ticky profiling, and it dawned on us that ticky probably isn't reported when the program is interrupted via the user. But it should be! The motivating case is when you're dealing with an infinite loop and you want to find the binding that has a high entry count (i.e. it's the looping body). But the only way to move forward is to interrupt it, which doesn't spit out the reports. Fixing this would make ticky much more useful in such cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump
by GHC 24 Mar '16

24 Mar '16

#10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For example, I ran with -ddump-rule-firings -ddump-to-file when there were no rule firings. GHC should have created an empty foo.dump-rule-firings file. (Instead it left the existing foo.dump-rule-firings from a previous run intact, which could have been misleading if I didn't already know that the most recent run had no rule firings.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10162: Add unicode syntax for banana brackets
by GHC 24 Mar '16

24 Mar '16

#10162: Add unicode syntax for banana brackets -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While there is a “pretty” unicode alternative available for “-<“ within arrow notation (⤙), banana brackets can only be written as “(|” and “|)”, which is a bit of an eyesore when they are used in the middle of the fancy arrow glyphs. Maybe it would be convenient to add the following unicode alternatives, which to the best of my knowledge are mapped by default within the XCompose definitions shipped with XOrg. ⦆ right white parenthesis (U+2986) ⦅ left white parenthesis (U+2985) Alternatively, these would also correspond well with the plain ASCII syntax: ⦇ z notation left image bracket (U+2987) ⦈ z notation right image bracket (U+2988) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9